왜 PostgreSQL이죠? Part 2 — 빅테크는 왜 PostgreSQL을 선택했나
데이터베이스 세계에는 '규모가 커지면 관계형을 버려야 한다'는 오래된 요약이 있습니다. 그러나 Instagram은 수십억 사용자를 넘기며 PostgreSQL을 설계로 풀었고, Reddit은 Aurora PostgreSQL로 대규모 메타데이터 트래픽을 통합했으며, Zalando는 운영 자체를 오픈소스로 돌려주었습니다. 이 글은 공개 엔지니어링 글과 사례 연구를 출발점으로, 초당 처리량·지연·일관성처럼 서로 다른 성공 정의를 먼저 나눈 뒤 각 사례를 읽도록 돕습니다. 자체 호스팅 PostgreSQL과 AWS Aurora 같은 관리형 서비스가 맡는 역할을 분리해 서술하고, NoSQL·분산 DB와의 조합 속에서 PostgreSQL이 교체 대상이 아니라 정확성 계층으로 쓰이는 패턴을 정리합니다. 숫자와 아키텍처 결정 뒤에 숨은 운영 비용·팀 역량 요구까지 짚어, 같은 스택을 왜 택했는지의 맥락을 한 번에 잡습니다.
시리즈 구성
- Part 1 — 숫자로 보는 PostgreSQL의 현재 위치
- Part 2 — 빅테크는 왜 PostgreSQL을 선택했나 (현재 편)
- Part 3 — 스타트업의 선택: 속도와 비용의 최적점
- Part 4 — MongoDB·Oracle 탈출기: 실제 마이그레이션 사례
- Part 5 — 생태계 확장: pgvector, PostGIS, TimescaleDB
목차
- 들어가며: "규모가 커지면 버려야 하는 것 아닌가요?"
- Instagram — 10억 사용자와 함께 살아남은 PostgreSQL
- Spotify — 마이크로서비스 시대에 PostgreSQL이 맡은 역할
- Reddit — Aurora PostgreSQL로 메타데이터 트래픽을 단일화하다
- Zalando — 쓰는 것으로 모자라 직접 만들어 오픈소스로 공개했다
- Coinbase — 금융 트랜잭션 무결성의 최후 보루
- 공통점: 이 회사들이 PostgreSQL을 선택한 진짜 이유
- 마치며
1. 들어가며: "규모가 커지면 버려야 하는 것 아닌가요?"
데이터베이스 세계에는 오랫동안 통용되던 속설이 하나 있었습니다.
"처음엔 PostgreSQL이나 MySQL로 시작하되, 규모가 커지면 NoSQL이나 자체 솔루션으로 갈아타야 한다."
이 명제는 MongoDB, Cassandra, DynamoDB의 성장기를 뒷받침한 논리였습니다. 그런데 실제 빅테크 기업들의 기술 선택을 들여다보면, 이 속설과 다른 패턴이 보입니다.
이 글에서 다루는 사례를 읽을 때는 같은 숫자가 곧 같은 의미는 아니라는 전제를 먼저 두는 편이 안전합니다.
- 처리량(throughput): 초당 몇 건을 넘길 수 있는가.
- 지연(latency): p90·p99처럼 꼬리가 얼마나 짧게 유지되는가.
- 일관성(consistency): ACID·선형적 일관성·최종 일관성 중 무엇을 요구하는가.
Instagram이 강조한 "좋아요 초당 처리"와 Reddit이 공개한 "미디어 메타데이터 RPS"는 서로 다른 워크로드·측정 조건에서 나온 값입니다. 아래에서는 엔진으로서의 PostgreSQL이 갖는 성격과, AWS Aurora처럼 스토리지·복제·장애 조치를 클라우드가 감싼 관리형 PostgreSQL 호환 서비스가 더해 준 부분을 가능한 한 구분해 서술합니다.
Instagram은 10억 명 이상의 사용자를 PostgreSQL 위에서 처리했고, Reddit은 2024년 공개 사례에서 Aurora PostgreSQL 기반 스토어로 대규모 트래픽을 소화했으며, Zalando는 PostgreSQL 운영을 자동화하는 도구를 오픈소스로 내놓았습니다. 이 회사들이 PostgreSQL을 "그냥 쓴" 것인지, "의도적으로 선택하고 유지한" 것인지 — 그 기술적 맥락을 이 파트에서 정리합니다.
2. Instagram — 10억 사용자와 함께 살아남은 PostgreSQL
"초당 90개의 좋아요"에서 "초당 10,000개의 좋아요"로
Instagram이 처음 PostgreSQL을 도입한 것은 창업 초기였습니다. 당시 소수의 엔지니어 팀이 빠르게 제품을 만들어야 했고, PostgreSQL은 빠르게 검증하기 좋은 선택이었습니다. 문제는 그 이후입니다.
Instagram 엔지니어링 블로그에 따르면, 초당 90개의 좋아요를 처리하던 시스템이 불과 수년 만에 초당 10,000개 이상의 좋아요를 처리해야 하는 상황이 됐습니다. 이 수치는 공개 글에 예시로 인용된 시점의 스케일이며, 이후에도 계속 변했을 수 있습니다. 일반적인 시나리오라면 이 시점에 "PostgreSQL을 버리고 더 확장성 있는 시스템으로 교체"를 선택했을 것입니다. Instagram은 그렇게 하지 않았습니다.
공개 글에 등장하는 수치와 아키텍처는 연도마다 진화했습니다. 아래 설명은 블로그에 정리된 설계 원칙을 요약한 것이며, "지금 이 순간의 프로덕션 구성"과 1:1로 대응한다고 보기는 어렵습니다. 다만 **"SQL을 버리지 않고 확장을 풀었다"**는 방향성 자체는 여러 글에서 일관되게 드러납니다.
핵심 아키텍처: 샤딩과 커넥션 풀링
Instagram 엔지니어들이 선택한 방법은 PostgreSQL을 교체하는 것이 아니라, PostgreSQL을 분산 환경에 맞게 운영하는 방식을 바꾸는 것이었습니다.
수천 개의 논리적(logical) 샤드를 소수의 물리적(physical) PostgreSQL 샤드에 매핑하는 방식으로 데이터를 수평 분산했습니다. 동시에 백엔드 웹 서버와 PostgreSQL 사이에 PgBouncer를 커넥션 풀러로 배치해 연결 오버헤드를 줄였습니다. 시간 기반으로 정렬 가능한 고유 ID 생성 체계도 PostgreSQL 샤드 안에서 직접 구현했습니다 — 41비트 타임스탬프 + 13비트 샤드 ID + 10비트 자동 증가 시퀀스의 조합으로(합계 64비트 정수).
공개 자료에 따르면 Instagram의 PostgreSQL 클러스터는 가용 영역에 걸쳐 다수의 복제본을 운영하며, 쓰기는 리더(primary) 노드로 집중되고 읽기는 팔로워(replica)로 분산되는 형태를 취했습니다. 여기서 핵심은 애플리케이션·샤딩·풀링·복제 운영이 한 세트로 설계되었다는 점입니다. "PostgreSQL만 설치하면 자동으로 된다"가 아니라, 팀이 연속적으로 운영 과제를 풀었다에 가깝습니다.
왜 NoSQL로 완전 이전하지 않았나
Instagram이 Cassandra를 도입한 것은 사실입니다. 다만 Cassandra가 맡은 역할은 사용자 피드, 활동 로그, 분석 데이터처럼 eventual consistency가 허용되는 영역입니다. 반면 공개 블로그 기준으로, 사용자 프로필·댓글·팔로우 관계·사진 메타데이터처럼 정확성과 일관성이 필요한 구조적 데이터는 PostgreSQL 계층이 담당하는 것으로 설명됩니다(역할 분배는 시점·제품마다 달라질 수 있습니다).
"SQL은 확장되지 않는다"는 통념은 틀렸다는 것이 Instagram 쪽 결론에 가깝게 읽힙니다. 정확히는 **"잘못 모델링·운영된 SQL은 확장에 한계를 드러낸다"**가 맞는 표현일 것입니다.
3. Spotify — 마이크로서비스 시대에 PostgreSQL이 맡은 역할
마이크로서비스 시대의 PostgreSQL 포지셔닝
Spotify는 수백 개의 마이크로서비스로 구성된 아키텍처를 운영합니다. 이 구조에서 핵심 원칙 중 하나는 각 마이크로서비스가 자신의 데이터베이스를 소유한다는 것입니다.
이 환경에서 데이터베이스 선택은 단순한 기술 결정이 아니라 팀 자율성의 문제가 됩니다. Spotify의 선택은 역할에 따른 데이터베이스 분리였습니다. Cassandra와 BigTable은 고속 조회가 필요한 대규모 분산 데이터에, 관계형 DB(그중 PostgreSQL을 쓰는 서비스도 있다)는 과금·구독·계정 무결성처럼 ACID가 요구되는 도메인에 두는 패턴이 공개 발표에서 반복적으로 설명됩니다. 구체적인 서비스명·스택 매핑은 제품·시점마다 다릅니다.
ACID가 필요한 도메인에 관계형 DB를 두는 이유
과금·지갑·구독 상태처럼 돈과 직결된 데이터에서는 "한쪽만 반영됐다"는 종류의 불일치가 치명적입니다. NoSQL 계열에서 eventual consistency가 허용하는 트레이드오프는 이런 도메인과 잘 맞지 않는 경우가 많습니다. ACID 트랜잭션을 기대할 수 있는 관계형 DB가 자주 선택되는 이유입니다.
Spotify가 개인화 추천, 플레이리스트 메타데이터, 스트리밍 이벤트 처리를 위해 Cassandra 등 다른 저장소를 쓰면서도, 무결성 비용이 큰 경로에는 관계형 DB를 남겨 두는 패턴이 공개 자료에서 설명됩니다. 다만 "결제 서비스 = 항상 PostgreSQL"처럼 단정할 수 있는 단일 공식 URL 하나로 압축되지는 않으니, 패턴으로 이해하는 편이 안전합니다.
돈·계정과 관련된 경로에서 흔히 쓰는 패턴은, 단일 트랜잭션으로 상태를 맞추는 것입니다.
BEGIN;
UPDATE wallets SET balance = balance - 100 WHERE user_id = 'u1';
UPDATE wallets SET balance = balance + 100 WHERE user_id = 'u2';
COMMIT;
실제 서비스는 격리 수준, 재시도, 멱등 키뿐 아니라 잔액 조건·영향 행 수(row count) 검증 같은 추가 장치가 붙지만, 원자적으로 성공하거나 전부 되돌아간다는 요구는 PostgreSQL 같은 RDB가 잘 맞는 축입니다.
4. Reddit — Aurora PostgreSQL로 메타데이터 트래픽을 단일화하다
AWS Aurora PostgreSQL로 10만 RPS 처리 (2024 공개 사례)
Reddit은 수십억 개의 게시물과 서로 다른 유형의 미디어 콘텐츠를 호스팅합니다. 사용자 행동 트렌드는 미디어 콘텐츠 업로드가 계속 늘어나는 방향으로 움직이고 있습니다.
2024년 Reddit 엔지니어링 블로그가 공개한 프로젝트는 이 맥락에서 주목할 만합니다. Reddit은 미디어 메타데이터를 기존의 분산된 여러 시스템(객체 스토어·다른 DB 등, 공개 글에 따르면 S3 등에서 메타를 직접 조회해야 하는 경로도 있었음)에서 AWS Aurora PostgreSQL 기반의 단일화된 미디어 메타데이터 스토어로 통합했습니다.
공개된 수치는 초당 10만 건 이상의 요청, p90 레이턴시 5ms 이하로 소개되었습니다. 이 수치가 의미 있는 이유는 단순히 "빠르다"가 아니라, 해당 워크로드(미디어 메타데이터 조회·쓰기) 에서 Aurora PostgreSQL 호환 스토어가 목표를 달성했다는 사례 증명에 가깝습니다. 범용 벤치마크에서의 "PostgreSQL 단일 인스턴스 한계"와 바로 비교하는 용도는 아닙니다.
여기서 중요한 구분은, PostgreSQL 엔진의 SQL·확장 모델이 주는 이점과, Aurora가 스토리지·복제·장애 복구 층에서 제공하는 운영 특성이 합쳐졌다는 점입니다. self-hosted PostgreSQL을 직접 샤딩·백업·페일오버하는 부담을 팀이 일부 넘긴 선택으로 읽을 수 있습니다.
마이그레이션 전략: 이중 쓰기와 단계적 전환
이 프로젝트에서 Reddit이 선택한 마이그레이션 방식도 주목할 만합니다. 단번에 전환하는 빅뱅 방식 대신, 다음의 단계적 접근을 택했습니다.
먼저 이중 쓰기(dual write)를 활성화해 새 데이터 스토어와 기존 시스템을 병렬 운영했습니다. 이후 이중 읽기(dual read)를 활성화해 두 시스템의 출력을 비교하고 불일치를 탐지했습니다. 마지막으로 새 데이터 스토어로의 읽기를 점진적으로 전환하면서 지속적으로 성능과 안정성을 모니터링했습니다. 이 과정에서 CDC·변경 이벤트 스트리밍으로 소스와 신규 스토어를 대조해 불일치를 잡는 파이프라인을 두었다고 공개 기술 글·요약 보도에서 설명됩니다(일부 자료에서는 Apache Kafka 컨슈머를 명시합니다).
이 접근은 "PostgreSQL을 선택한 이유"만큼이나 **"어떻게 PostgreSQL(호환) 스토어로 안전하게 이전했는가"**의 모범 사례로 읽을 수 있습니다. 이중 쓰기·검증·점진 전환은 팀 역량과 운영 예산이 함께 가야 하는 작업입니다.
Reddit 사례: 단계적 전환(개념도)
5. Zalando — 쓰는 것으로 모자라 직접 만들어 오픈소스로 공개했다
유럽 최대 패션 플랫폼이 PostgreSQL에 베팅한 방식
Zalando는 유럽 최대 온라인 패션 플랫폼으로, 수백만 개의 상품과 수많은 트랜잭션을 처리합니다. 이들이 PostgreSQL 생태계에 남긴 흔적은 단순한 사용 사례를 넘어섭니다.
Zalando 엔지니어링팀이 만들어 오픈소스로 공개한 postgres-operator는 Kubernetes 환경에서 PostgreSQL 클러스터를 자동으로 생성하고 관리하는 도구입니다. KubeCon 등 공개 발표·블로그에 따르면, Zalando 프로덕션에서 수백 개 규모의 PostgreSQL 클러스터를 이 오퍼레이터로 운영한다고 소개됩니다(시점·정의에 따라 수치는 달라질 수 있습니다).
postgres-operator가 해결한 문제
Kubernetes 위에서 PostgreSQL을 운영하는 것은 쉽지 않습니다. 스테이트풀(stateful) 워크로드는 스테이트리스(stateless) 워크로드와 다른 방식으로 관리해야 하기 때문입니다. postgres-operator는 이 복잡성을 추상화합니다.
이 오퍼레이터가 제공하는 주요 기능으로는 Patroni 기반의 자동 장애 조치(failover), CRD로 클러스터를 선언적으로 정의하는 방식, 스토리지 리사이즈, 클라우드 환경에서의 복원·클론 등이 알려져 있습니다. PostgreSQL 확장(pgvector, PostGIS, TimescaleDB 등)은 버전·이미지·클러스터 설정에 따라 연동 가능 여부가 달라지므로, 필요 시 공식 문서·예제를 확인하는 편이 좋습니다.
중요한 것은 이것이 Zalando의 내부 도구에 그치지 않는다는 점입니다. Google Cloud 문서가 GKE 환경에서 PostgreSQL을 배포하는 예시로 Zalando postgres-operator를 인용할 정도로, 널리 참조되는 스택이 되었습니다.
"쓰는 것을 만들어서 공개한다"는 철학
Zalando가 postgres-operator를 오픈소스로 공개한 것은 단순한 선의의 행동만은 아닙니다. PostgreSQL 생태계를 강화함으로써 자신들도 혜택을 받는 선순환 구조를 만드는 전략적 선택으로 읽을 수 있습니다. Instagram 엔지니어링팀이 PostgreSQL 운영 경험을 블로그로 공유하고, Zalando가 운영 도구를 오픈소스로 내놓는 패턴은, 이 기업들이 PostgreSQL을 단순한 벤더 제품이 아니라 함께 키우는 공유 인프라로 바라보고 있다는 신호입니다.
다만 오퍼레이터를 도입했다고 끝이 아닙니다. Kubernetes·Patroni·백업·업그레이드 정책까지 포함한 운영 모델을 갖춘 팀에게 실효가 큰 도구입니다.
6. Coinbase — 금융 트랜잭션 무결성의 최후 보루
암호화폐 거래소에서 ACID가 의미하는 것
Coinbase는 암호화폐 거래소입니다. 이 산업에서 데이터베이스 선택의 핵심 기준은 단 하나에 가깝습니다 — 트랜잭션 정확성입니다.
암호화폐 거래는 "이 사용자의 BTC 잔고에서 0.5 BTC를 빼고, 다른 사용자의 잔고에 0.5 BTC를 추가한다"는 작업입니다. 이 두 작업이 원자적(atomic)으로 실행되지 않으면 — 즉, 하나는 성공하고 하나는 실패하는 상황이 발생하면 — 그것은 단순한 버그가 아니라 금융 사고로 이어질 수 있습니다.
PostgreSQL의 ACID 보장, 그중에서도 원자성(Atomicity)과 격리성(Isolation)은 이 요구사항을 충족하는 검증된 방법 중 하나입니다. Coinbase의 공개 엔지니어링 글 등에서는 핵심 계정·거래 데이터에 PostgreSQL 계열 RDB를 포함한 스택을 쓴다는 서술이 있으나, 전사가 단일 제품만 쓴다고 단정할 수는 없습니다.
규모와 정확성의 균형
Coinbase가 처리하는 거래량은 기관 투자자와 리테일 유저를 합산해 매우 큰 규모입니다. 이 규모에서도 PostgreSQL을 유지하는 것은, 정확성을 포기하지 않고도 엔진·운영·하드웨어·아키텍처의 조합으로 요구 수준을 맞출 수 있다는 선택으로 읽을 수 있습니다.
패턴 요약: 정확성 계층과 보조 스토어(개념도)
7. 공통점: 이 회사들이 PostgreSQL을 선택한 진짜 이유
다섯 회사의 사례를 관통하는 공통적인 패턴이 있습니다.
첫째, 정확성이 필요한 곳에 PostgreSQL을 배치했습니다. 사용자 프로필, 결제, 금융 트랜잭션, 일부 메타데이터 — 이 데이터들의 공통점은 "틀렸을 때의 비용이 높다"는 것입니다. eventual consistency를 허용하는 NoSQL이 주 저장소로 적합하지 않은 영역이 분명히 존재합니다. (동시에 특정 제품·도메인에서는 NoSQL이 주력이 되는 경우도 있으니, 이번에 살펴본 사례군으로 범위를 한정해 이해하는 것이 좋습니다.)
둘째, PostgreSQL을 "없앤" 것이 아니라 운영·주변 계층을 혁신했습니다. Instagram은 샤딩과 커넥션 풀링으로, Reddit은 Aurora로, Zalando는 Kubernetes 오퍼레이터로 확장성·운영 과제를 풀었습니다. 문제는 "SQL 자체가 한계"라기보다 **"어떻게 경계를 나누고 무엇에 맞출 것인가"**에 가깝습니다.
셋째, 선택의 경험을 생태계에 돌려줬습니다. Instagram의 엔지니어링 블로그, Zalando의 postgres-operator, Reddit의 마이그레이션 사례. 이들의 경험 공유가 PostgreSQL 생태계 전체의 수준을 끌어올렸습니다.
넷째, 멀티 데이터베이스 전략 속에서도 PostgreSQL이 중심 축 중 하나였습니다. Spotify는 Cassandra, BigTable과 함께 쓰면서도, ACID가 중요한 서비스에는 관계형 DB(그중 PostgreSQL을 쓰는 경우 포함)를 두는 패턴이 공개 자료에서 설명됩니다. Instagram 역시 Cassandra를 도입했지만 구조적 데이터의 핵심은 PostgreSQL이 맡았습니다.
다섯째, "왜 PostgreSQL이냐"와 함께 "누가 감당할 수 있느냐"가 붙어 있습니다. 샤딩·이중 쓰기·오퍼레이터 업그레이드는 숨은 운영 비용입니다. 같은 기술 스택이라도 조직 성숙도에 따라 난이도는 달라집니다.
8. 마치며
이 회사들의 사례를 요약하면 다음 한 문장이 됩니다.
이번에 다룬 빅테크 사례에서는, NoSQL·분산 DB는 PostgreSQL의 단순 대체재라기보다, PostgreSQL이 맡지 않는 역할을 보완하는 도구로 자주 등장합니다.
PostgreSQL이 규모에서 살아남을 수 있었던 것은 "운이 좋아서"만은 아닙니다. 수십 년에 걸쳐 검증된 ACID 보장, 활발한 커뮤니티, 확장 가능한 아키텍처, 그리고 이를 운영 수준으로 끌어올린 엔지니어들의 경험이 축적된 결과입니다.
Part 3에서는 시각을 스타트업으로 옮깁니다. 빅테크와 달리 자원이 제한된 스타트업이 PostgreSQL을 선택하는 이유는 무엇인지, 그리고 초기 아키텍처 선택이 성장 경로에 어떤 영향을 미치는지를 다룹니다.
다음 편 예고 — Part 3: 스타트업의 선택 — 속도와 비용의 최적점
Supabase를 백엔드로 선택한 수많은 스타트업, pgvector 하나로 벡터 DB 비용을 줄인 AI 스타트업들, "데이터 웨어하우스를 삭제하고 PostgreSQL만 남겼다"는 팀의 이야기까지. 자원이 제한될수록 PostgreSQL이 더 강력한 선택이 되는 이유를 살펴봅니다.
참고·출처
- Instagram Engineering — Sharding & IDs at Instagram (2012) — 논리 샤드·PgBouncer·ID 비트 배분
- Spotify — 공개 블로그·발표의 마이크로서비스·데이터 소유권·스토어 선택(제품별 매핑은 시점마다 다름)
- Reddit — Reddit Inc. Engineering 블로그 및 미디어 메타데이터·Aurora 관련 2024 기술 요약(예: InfoQ) — 수치·마이그레이션 단계는 원문·2차 요약 기준
- Zalando postgres-operator (GitHub)
- Google Cloud — PostgreSQL on GKE
- Coinbase — 공개 엔지니어링·아키텍처 자료
- PostgreSQL Documentation — Transaction Isolation · MVCC
- AWS Aurora PostgreSQL
작성: 2026년 4월 · 사례별 수치·구성은 공개 시점의 블로그·발표를 기준으로 하며, 이후 인프라는 변경될 수 있습니다. 인용 시 원문을 확인하세요.