상황
신규 주문 서비스의 DB를 정하는 회의에서 동료가 "나중에 트래픽 커질 테니 처음부터 MongoDB로 가자"고 한다. 지금 트래픽은 하루 주문 몇천 건 수준이다.
😴 Boring — PostgreSQL (관계형 DB)
언제: 거의 항상, 특히 서비스 초기. 데이터 모양과 쿼리 패턴이 아직 바뀌는 중이고, 트랜잭션과 조인이 필요할 때. 패턴이 바뀌어도 인덱스와 쿼리로 따라갈 수 있다.
비용: 단일 노드 쓰기 한계가 있다. 테이블이 수억 행으로 커지면 스키마 변경(ALTER)이 무거워지고, 그 이상은 샤딩이라는 큰 공사가 필요하다.
✨ Novel — DynamoDB / MongoDB (NoSQL)
언제: 액세스 패턴이 키 조회 몇 개로 완전히 굳었고, 실측 트래픽이 단일 노드 한계를 넘는 게 숫자로 증명됐을 때. 전체가 아니라 그 테이블 하나만 분리해서 옮긴다.
비용: 조인과 애드혹 쿼리를 포기한다. 액세스 패턴이 바뀌면 테이블 설계를 처음부터 다시 해야 하고, 백업·모니터링 같은 운영 노하우도 따로 쌓아야 한다.
⚖️ 기본 판단
기본은 무조건 Postgres로 시작한다. 초기에는 쿼리 패턴을 모르는데, 관계형은 패턴이 바뀌어도 인덱스 추가로 따라갈 수 있기 때문이다. 쓰기 규모가 실측으로 단일 노드 한계를 넘고 액세스 패턴이 키 조회로 굳은 게 확인된 그 테이블만 NoSQL로 뺀다.
🚨 트립와이어 — 이 신호가 오면 바꾼다
- 인덱스·쿼리 튜닝을 다 했는데도 단순 PK 조회 p99가 200ms를 넘는 상태가 유지된다
- 쓰기가 늘면서 리플리카 랙이 5초 이상 벌어지고, 커넥션 풀 고갈 알람이 매주 반복된다
- 테이블 하나가 수억 행을 넘어 ALTER 한 번에 몇 시간씩 걸려 배포가 막힌다
- 전체 쿼리의 90% 이상이 PK 단건 조회 — 조인 등 관계형의 장점을 사실상 안 쓰고 있다
🔧PostgreSQLMySQLDynamoDBMongoDBRedis
🗣 영어 한 줄 평결
“I default to Postgres; I'd only reach for NoSQL once real traffic proves a single node can't keep up.”
checking microphone…