Kafka는 빠르다 — 나는 Postgres를 쓸 것이다

• Postgres의 퍼블리시/서브스크라이브(pub-sub) 및 큐(queue) 성능을 벤치마크해, 단일 데이터베이스로도 메시징 시스템을 대체할 수 있는 가능성 제시
• 단일 4vCPU 노드에서 초당 5,036건 쓰기·25,183건 읽기, 3노드 복제 환경에서도 유사한 처리량 유지, 엔드투엔드 지연 186ms(p99) 수준
• 대형 96vCPU 노드에서는 쓰기 238MiB/s, 읽기 1.16GiB/s 달성, CPU 사용률 10% 미만으로 여유 있는 처리 확인
• 큐 테스트에서도 단일 노드 기준 초당 2,885건, 복제 환경에서도 2,397건 처리 가능, 대부분의 기업 규모에 충분한 성능
• 복잡한 분산 시스템 대신 Postgres 단일 인프라로도 수 MB/s 규모의 워크로드 처리 가능성을 입증, “필요할 때까지 단순한 기술을 사용하라”는 실용적 접근 강조

기술 선택의 두 진영

• 기술 업계는 유행어 중심 진영과 상식 중심 진영으로 나뉨
  • 전자는 “실시간”, “무한 확장”, “AI 기반” 등 마케팅 용어에 끌림
  • 후자는 단순성과 실용성을 중시하며, 불필요한 복잡성을 피함
• 최근 Small Data와 Postgres 르네상스 두 흐름이 후자에 힘을 실음
  • 데이터는 작아지고 하드웨어는 강력해짐
  • Postgres는 단일 시스템으로 다양한 목적형 솔루션을 대체 가능 (jsonb, pgvector, tsvector 등)

벤치마크 개요

• 목적: Postgres가 pub/sub 메시징과 큐 처리에서 어느 정도 확장 가능한지 측정
• 테스트 환경: AWS EC2 c7i.xlarge(4vCPU) 및 c7i.24xlarge(96vCPU)
• 세 가지 구성 비교
  • 단일 노드
  • 3노드 복제 클러스터
  • 대형 단일 노드

Pub/Sub 벤치마크 결과

• 4vCPU 단일 노드
  • 쓰기 4.8MiB/s(5,036msg/s), 읽기 24.6MiB/s(25,183msg/s), 지연 60ms(p99)
  • CPU 60% 사용, 디스크 46MiB/s 쓰기
• 4vCPU 3노드 복제
  • 쓰기 4.9MiB/s, 읽기 24.5MiB/s, 지연 186ms(p99)
  • 처리량 유지, 연간 비용 약 $11,514
• 96vCPU 단일 노드
  • 쓰기 238MiB/s(243kmsg/s), 읽기 1.16GiB/s(1.2Mmsg/s), 지연 853ms(p99)
  • CPU 10% 미만, 병목은 파티션당 쓰기 속도
• 결론: 저·중규모 워크로드에서 Kafka와 경쟁 가능한 수준, 단순한 구조로도 수십 MB/s 처리 가능

Queue 벤치마크 결과

• SELECT FOR UPDATE SKIP LOCKED 기반 단순 큐 구현
• 4vCPU 단일 노드
  • 2.81MiB/s(2,885msg/s), 지연 17.7ms(p99), CPU 60%
• 4vCPU 3노드 복제
  • 2.34MiB/s(2,397msg/s), 지연 920ms(p99), CPU 60%
• 96vCPU 단일 노드
  • 19.7MiB/s(20,144msg/s), 지연 930ms(p99), CPU 40~60%
• 단일 노드로도 대부분 기업의 큐 처리량 요구 충족 가능

Postgres 사용 판단

• 대부분의 경우 Postgres 기본 선택이 합리적
  • SQL로 메시지 디버깅, 수정, 조인 가능
  • Kafka 대비 운영 단순성 및 유지보수 용이
• Kafka는 고성능에 최적화, 그러나 소규모 워크로드에는 과도한 선택
• “조기 최적화는 모든 악의 근원”이라는 Donald Knuth의 경고 인용
  • 수 MB/s 수준까지는 Postgres로 충분

최소 실행 인프라(MVI) 접근

• Minimum Viable Infrastructure: 조직이 이미 익숙한 기술로 최소한의 시스템 구축
  • Postgres는 널리 채택되고 인력 확보 용이
  • 구성 요소가 적을수록 장애·운영 부담 감소
• 불필요한 기술 도입은 조직적 오버헤드를 초래
  • 학습, 모니터링, 배포, 운영 비용 증가

확장성 논의

• Postgres는 실제로 확장 가능
  • OpenAI는 여전히 단일 쓰기 인스턴스 기반 Postgres 사용
  • 수억 명 사용자 규모에서도 안정적 운영
• 대부분의 기업은 성장 속도가 완만해, 기술 교체까지 수년의 여유 존재
• “바이럴 대비 설계”는 과도한 오버디자인
  • “Coldplay 오프닝을 위해 마샬 앰프를 사는 것과 같다”는 비유 제시

결론

• “깨질 때까지 Postgres를 써라”
  • 단순한 기술로도 충분히 높은 성능 확보 가능
  • 필요 이상으로 복잡한 분산 시스템 도입은 비효율적
  • Postgres는 현대 하드웨어와 함께 대부분의 워크로드를 감당할 수 있는 실용적 선택지