▲

2026년, 그냥 Postgres를 쓰면 된다

 (tigerdata.com)
2P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • Postgres는 검색, 벡터, 시계열, 큐 등 다양한 기능을 하나의 데이터베이스에서 처리할 수 있는 통합 플랫폼임
  • 여러 전문 데이터베이스를 사용하는 방식은 관리 복잡도, 보안, 백업, 장애 대응 등에서 비효율과 위험을 초래함
  • AI 시대에는 데이터베이스를 빠르게 복제·테스트·삭제해야 하므로, 단일 시스템 구조가 단순성과 민첩성을 보장함
  • Postgres의 확장 기능(extensions) 은 Elasticsearch, Pinecone, InfluxDB 등과 동일한 알고리듬을 사용하며, 성능도 입증됨
  • 대부분의 기업(99%)은 Postgres 하나로 충분하며, 복잡한 분산 구조는 극소수 대규모 기업에만 필요함

데이터베이스 통합의 필요성

  • 데이터베이스를 집에 비유하며, Postgres는 여러 기능을 한 지붕 아래 통합한 구조로 설명
    • 검색, 벡터, 시계열, 큐 등 다양한 용도를 하나의 시스템에서 처리 가능
  • 반면, “적재적소의 도구를 사용하라”는 조언은 결과적으로 여러 데이터베이스를 병행 운영하게 만듦
    • Elasticsearch, Pinecone, Redis, MongoDB, Kafka, InfluxDB, PostgreSQL 등 7개 시스템을 예로 제시
    • 각각의 쿼리 언어, 백업, 보안, 모니터링, 장애 대응을 따로 관리해야 함
  • 이러한 분산 구조는 테스트 환경 구성과 문제 해결을 어렵게 함, 특히 새벽 장애 대응 시 복잡성이 극대화됨

AI 시대의 단순성

  • AI 에이전트는 테스트용 데이터베이스를 빠르게 생성·검증·삭제해야 함
    • 단일 데이터베이스에서는 한 번의 명령으로 가능하지만, 여러 시스템에서는 스냅샷 동기화와 설정 조정이 필요
  • 여러 데이터베이스를 동시에 관리하는 것은 R&D 수준의 복잡도를 요구
  • AI 시대에는 단순성이 필수 요소로 강조됨

전문 데이터베이스의 ‘우월성’ 신화

  • 전문 데이터베이스가 특정 작업에 더 뛰어나다는 인식은 과장된 마케팅 효과로 지적
    • 실제로는 Postgres 확장이 동일하거나 더 나은 알고리듬을 사용
  • 비교 표에 따르면 Postgres 확장은 다음과 같은 대응 관계를 가짐
    기능 전문 DB Postgres 확장 동일 알고리듬
    전체 텍스트 검색 Elasticsearch pg_textsearch BM25
    벡터 검색 Pinecone pgvector + pgvectorscale HNSW/DiskANN
    시계열 InfluxDB TimescaleDB 시간 파티셔닝
    캐싱 Redis UNLOGGED tables 메모리 기반 저장
    문서 MongoDB JSONB 문서 인덱싱
    공간정보 GIS PostGIS 산업 표준
  • pgvectorscale은 Pinecone 대비 28배 낮은 지연시간, 75% 낮은 비용을 기록
  • TimescaleDB는 InfluxDB와 동등하거나 우수한 성능을 제공하며, pg_textsearch는 Elasticsearch와 동일한 BM25 랭킹을 사용

데이터베이스 분산의 숨은 비용

  • 여러 시스템을 운영하면 백업, 모니터링, 보안 패치, 장애 대응 등 모든 관리 비용이 7배로 증가
  • 인지 부하: SQL, Redis, Elasticsearch DSL, MongoDB, Kafka, InfluxDB 등 다양한 언어를 학습해야 함
  • 데이터 일관성 문제: Postgres와 Elasticsearch 간 동기화 실패로 데이터 드리프트 발생
  • 가용성 저하: 여러 시스템의 SLA가 곱해져 전체 가동률이 낮아짐 (예: 99.9% × 3 = 99.7%)

현대적 Postgres 스택

  • Postgres 확장은 이미 수년간 실서비스에서 검증됨
    • PostGIS(2001), Full-text search(2008), JSONB(2014), TimescaleDB(2017), pgvector(2021)
  • Netflix, Spotify, Uber, Reddit, Instagram, Discord 등 48,000개 이상 기업이 PostgreSQL 사용
  • AI 시대 확장 기능
    확장 대체 대상 특징
    pgvectorscale Pinecone, Qdrant DiskANN 알고리듬, 28배 낮은 지연, 75% 비용 절감
    pg_textsearch Elasticsearch BM25 랭킹을 Postgres에 직접 구현
    pgai 외부 AI 파이프라인 데이터 변경 시 임베딩 자동 동기화
  • 하나의 Postgres로 RAG 애플리케이션 구축 가능: 단일 쿼리 언어, 단일 백업, 단일 테스트 환경

주요 확장 기능 예시

  • pg_textsearch: Elasticsearch 대체, BM25 기반 검색 지원
  • pgvector + pgvectorscale: Pinecone 대체, DiskANN 기반 벡터 검색
  • TimescaleDB: InfluxDB 대체, 시계열 데이터 압축 및 SQL 지원
  • UNLOGGED tables: Redis 대체, 캐시 테이블 구현
  • pgmq: Kafka 대체, 메시지 큐 기능 제공
  • JSONB: MongoDB 대체, 문서형 데이터 저장 및 인덱싱
  • PostGIS: 공간정보 처리 지원
  • pg_cron: 스케줄링 작업 자동화
  • pg_trgm: 오타 허용 검색 지원
  • Recursive CTEs: 그래프 탐색 기능 구현

결론

  • Postgres는 하나의 집 안에 여러 방이 있는 구조로, 다양한 데이터 처리 기능을 통합 제공
  • 대부분의 기업(99%)은 Postgres 하나로 충분하며, 극소수(1%)만이 초대규모 분산 시스템이 필요
  • “적재적소의 도구”라는 조언은 데이터베이스 판매를 위한 마케팅 논리로 지적
  • Postgres로 시작하고, 필요할 때만 복잡성을 추가하라는 원칙 제시
  • 2026년, 그냥 Postgres를 쓰면 된다는 결론으로 마무리
▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • 로컬 퍼스트 앱에 Postgres를 임베드하기가 어렵고, Docker 설정을 강제해야 하는 점이 불편함
    PGlite가 여러 writer 연결을 지원했다면 완벽했을 것임. SQLite도 괜찮지만, PG 확장 기능과 진짜 병렬 multi-writer 지원을 원함

  • 오랜만에 데이터베이스를 다시 공부해보니 Postgres가 정말 마법 같은 시스템임
    수천만 행을 여러 테이블에 넣고 인덱스만 잘 잡으면 거의 모든 쿼리가 100ms 이하로 응답함
    실행 계획을 분석해보면 바로 어떤 인덱스를 추가해야 할지 알 수 있어서 놀라움. 현대 DB는 진짜 기적임

    • 네가 말한 건 사실 ‘현대’ DB의 특징이라기보다 20년 전 Postgres에서도 가능했던 일임
      물론 지금은 훨씬 좋아졌지만, 대부분의 발전은 고급 쿼리 기능이나 운영 관련 최적화 쪽임
    • 관계형 DB는 수십 년 전부터 그런 성능을 보여줬음. Postgres만의 특성은 아님

  • 나는 Postgres 팬이지만 “그냥 Postgres 쓰면 된다”는 조언에는 동의하지 않음
    Postgres 하나로 단순화된 스택을 구성하는 건 좋지만, 그게 모든 워크로드에 효율적인 건 아님
    Citus Data 시절, Postgres 전문가 팀이 상시 튜닝과 운영에 매달려야 했던 사례를 많이 봤음
    AI 기반 유즈케이스가 늘면서 전용 기술이 훨씬 일찍 도입되는 추세임
    자세한 내용은 ClickHouse 블로그에 정리되어 있음
    Postgres와 목적형 기술을 통합적으로 활용하는 접근이 더 낫다고 생각함

    • “항상 Postgres만 써라”가 아니라 “기본값으로 Postgres를 고려하라”는 의미로 이해했음
    • 나도 “Postgres를 쓰되, 필요할 때 다른 걸로 바꾸라”는 입장임. 단순한 스택이 빠른 반복 개발에 유리함
    • 사실 Postgres 안에도 많은 전용 시스템 기능이 들어있음. 매뉴얼을 읽고 튜닝하면 충분히 대체 가능함
    • 결국 유즈케이스가 다르다는 게 핵심임. MySQL과 Postgres 비교 참고
    • 요즘 개발자들이 너무 하이프에 휩쓸려 기술을 맹신하는 게 문제라고 생각함
      특정 기술이 표준이 되면 개발자는 교체 가능한 부품이 되어버림. React 개발자처럼 말임
      기술 단일화는 기업 입장에선 인력 교체를 쉽게 만드는 전략임. 도구의 다양성을 지켜야 함

  • 나도 Postgres를 자주 쓰지만, 때로는 단순함이 더 중요함
    데이터 탐색이나 GIS 작업엔 Postgres.app이 완벽하지만, 간단한 서버엔 SQLite가 더 나을 때도 있음

    • SQLite로 단순하게 시작해도 금방 불편함에 부딪힘. Postgres는 “설치 후 잊어버려도 되는” 수준임
      작은 데이터 분석에서도 SQLite보다 Postgres가 훨씬 빠름. 인덱스나 기능 차이가 큼
    • SQLite는 통합 테스트용으로 최고임. 컨테이너 없이 DB를 쉽게 띄웠다 내릴 수 있음
    • SQLite는 임시 데이터 처리나 로컬 저장 파일용으로도 유용함.
      하지만 99%의 경우엔 Postgres를 씀. 안정적이고 확장성 높고, Oracle이나 MySQL보다 낫다고 느낌
    • Postgres에서 특정 DB만 접근 가능한 권한 설정이 어렵다는 점이 불편함.
      GRANT ALL PRIVILEGES가 항상 통하지 않음
    • “어떤 DB를 써야 하나” 논의는 너무 복잡한 변수가 많음
      Postgres는 무료, 빠르고, 공유 앱엔 좋지만, SQLite는 혼자 개발하는 사람에게 최적임

  • 결국 유즈케이스에 따라 다름
    우리도 예전엔 MariaDB 기반 검색을 쓰다가 Elasticsearch로 옮겼는데, 속도와 단순함이 훨씬 좋았음
    하지만 단순 검색이라면 Postgres로 충분함.
    새로운 도구로 옮기기 전엔 기다려보는 게 낫고, 필요할 때만 전환하는 게 효율적임

  • Pinecone이나 Redis 같은 DB는 특정 용도에선 비용 효율이 훨씬 좋음
    하지만 상황에 따라 Postgres로 해결하는 게 나을 때도 있음.
    결국 규모와 운영팀 유무에 따라 판단해야 함

    • 실제 앱과 데이터가 생긴 뒤에야 올바른 대안을 고르기 쉬움
      Postgres는 대부분의 초기 단계에 충분하고, 커진 뒤에 다른 솔루션을 검토하면 됨

  • 최근엔 Postgres 대신 MySQL과 SQLite로 이동 중임.
    Postgres의 vacuum, 유지보수, footgun이 귀찮음

    • MySQL은 운영 부담이 거의 없음. Postgres는 계속 손봐야 하지만 MySQL은 그냥 잘 돌아감
    • SQLite도 유지보수가 적지만, 공간 누적 방지를 위해 VACUUM 실행은 필요함
    • MySQL은 관리가 쉽지만, 고급 기능(BRIN, partial index 등)을 포기해야 함
      다만 클러스터링 인덱스를 잘 설계하면 범위 스캔이 매우 빠름
    • 나도 MySQL로 옮길까 고민했음. 업그레이드가 쉽지만 발전 속도는 Postgres보다 느림
    • Postgres의 Zheap 프로젝트가 중단된 게 아쉬움.
      VACUUM 없는 스토리지 엔진이 필요함. Zheap 위키 참고

  • Postgres는 훌륭하지만 두 가지 근본적인 문제가 있음
    첫째, Postgres는 통합 도구가 아니라 도구 모음이라 학습량이 많음
    둘째, Postgres는 HDD 기반 설계라 SSD 시대엔 비효율적일 수 있음
    SSD 전용 RDBMS가 더 단순하고 빠를 가능성이 큼

    • Postgres가 HDD 기반이라는 근거가 궁금함. 출처를 알고 싶음

  • Postgres의 클러스터링(HA) 구성이 너무 복잡함
    Patroni, Spilo, timescaledb-ha 등 도구가 있지만 관리가 어렵고 문서도 부족함
    CloudNativePG가 유일하게 쉬운 방법이지만 Kubernetes 의존성이 있음
    MongoDB처럼 간단히 replica set을 구성할 수 있으면 좋겠음

    • 하지만 Postgres는 CP DB가 아니며, 네트워크 분할 시 쓰기 손실이 발생할 수 있음
      Jepsen 테스트를 통과하려면 구조적 변화가 필요함 (Yugabyte, Neon처럼)

  • Postgres를 캐시로 쓰는 것에 대한 의견이 있음
    Redis가 훨씬 빠르지만, 규모가 작으면 Postgres로도 충분함

    • 캐시가 필요하다면 memcache가 단순하고 안정적임.
      수십억 요청을 처리해도 재시작 없이 잘 돌아감
    • Redis가 정말 필요한지 벤치마크로 증명해야 함. 의미 있는 차이가 없다면 Postgres로 충분함
    • Redis와 비교할 땐 unlogged table을 써야 함. 내구성 기능을 끄면 속도가 훨씬 빨라짐
    • 앱의 캐시 요구가 크지 않다면 Postgres로 시작하고,
      stateless 서버 구조라면 Redis를 고려할 만함. JVM 기반 장기 프로세스라면 자체 캐시도 가능함
    • Postgres의 materialized view도 꽤 유용함.
      다만 부하가 커지면 외부 캐시가 필요하고, 트랜잭션 일관성은 포기해야 함
답변달기