PgDog이 투자 유치를 완료하고 가까운 데이터베이스로 찾아옵니다

 (pgdog.dev)
1P by GN⁺ | ★ favorite | 댓글 1개
  • PgDog은 PostgreSQL 앞단에 두는 프록시로, 애플리케이션 재작성 없이 연결 풀링·로드 밸런싱·샤딩을 통해 Postgres를 수평 확장하게 함
  • Mongo나 Dynamo 같은 데이터베이스가 존재하는 이유를 Postgres의 확장 문제로 보고, 100TB 이상 테이블과 초당 100만 쿼리를 처리할 수 있다면 다른 데이터베이스가 필요 없다고 봄
  • PgDog은 프로덕션에서 초당 200만 건 이상 쿼리를 처리하고, 확인된 범위에서 20TB 이상을 샤딩했으며, GitHub Docker pull이 140만 회를 넘음
  • 세 명 규모 팀이 Postgres 기반 대규모 애플리케이션과 Instacart의 2020년 4월 5배 확장 경험을 바탕으로 RDS, Aurora, EC2에서 Postgres 샤딩 문제를 다뤘음
  • Basis Set, YC, Pioneer Fund 등으로부터 550만 달러를 유치했으며, PgDog을 모든 규모에서 Postgres가 작동하게 만드는 오픈소스 제품으로 구축 중임

투자 유치와 제품 방향

  • Postgres가 필요한 유일한 데이터베이스라는 관점에서 PgDog 개발이 시작됨
  • Mongo나 Dynamo 같은 데이터베이스가 존재하는 이유를 Postgres의 확장 문제로 봄
  • Postgres가 100TB 이상 테이블과 초당 100만 쿼리를 제대로 처리할 수 있다면 다른 데이터베이스를 쓰지 않을 것이라고 봄
  • PgDog은 기존 Postgres 앞에 프록시를 두어 수평 확장을 가능하게 함
  • PgDog은 온프레미스와 사용자의 클라우드 계정 등 어디에나 배포할 수 있음
  • Docker 이미지를 가져오고 DATABASE_URL을 바꾸면 PgDog이 작업을 맡는 방식임

현황과 실행 배경

  • 현재 상태

    • PgDog은 프로덕션의 수십 개 배포 환경에서 초당 200만 건 이상의 쿼리를 처리 중임
    • 확인된 범위에서 PgDog은 20TB 이상을 샤딩했음
    • PgDog은 오픈소스이며 누구나 배포할 수 있음
    • GitHub에서 Docker pull이 140만 회를 넘었음
    • 새 버전은 매주 목요일마다 나옴
    • Discord 커뮤니티가 성장 중이며, 매일 질문 응답과 지원이 이뤄짐

  • 팀과 신뢰 근거

    • PgDog은 세 명 규모의 작은 스타트업임
    • 팀은 인프라 엔지니어, 애플리케이션 엔지니어, 제너럴리스트로 구성됨
    • 팀은 Postgres가 널리 주목받기 전부터 Postgres 기반 애플리케이션을 만들고 대규모로 작동하게 했음
    • Instacart에서 2020년 4월 회사가 5배 확장되는 동안 Postgres 운영 경험을 쌓았음
    • 당시 가장 큰 문제는 Postgres가 분당 수십만 건의 식료품 배송 주문을 처리하게 만드는 일이었음
    • RDS, Aurora, EC2에서 Postgres를 샤딩했으며, 기본 원리와 많은 코드로 실제 문제를 해결했음
    • 같은 기술이 현재 오픈소스 제품으로 제공됨

  • 배포 방식과 자금

    • PgDog 개발은 피벗이 아니며, Postgres 확장이 계속 유일한 목표임
    • PgDog은 사용자의 클라우드, 코로케이션 랙, 온프레미스, 노트북에서 실행되도록 만들어짐
    • PgDog은 의존성이나 숨겨진 서버리스 비용 없이 필요한 곳에서 작동함
    • CPU를 제공할 수 있으면 PgDog의 멀티스레드 코드가 모든 CPU를 사용함
    • Postgres 채택은 계속 증가할 것이라고 봄
    • Basis Set, YC, Pioneer Fund와 다른 투자자들로부터 550만 달러를 유치했으며, 수년치 런웨이를 확보함
    • 목표는 모든 사람과 모든 규모에서 Postgres가 제대로 작동하게 만드는 것임

  • Enterprise edition

    • PgDog의 Enterprise edition은 AWS에서 더 쉽게 실행할 수 있도록 개발 중임
    • Enterprise edition은 팀의 SLA 기반 지원을 제공함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Mongo나 Dynamo 같은 데이터베이스가 존재하는 이유가 Postgres의 스케일링 문제라고 하지만, 여러 곳에서 Postgres를 써보니 1순위 문제는 항상 고가용성이지 스케일링이 아니었음
    Postgres 클러스터 하나로 분당 10만 트랜잭션은 쉽게 처리했지만, 주 노드가 죽으면 호출을 받고 예비 노드로 수동 장애 조치한 뒤 예비 노드도 수동으로 교체해야 했음
    수동 도구는 매우 까다로웠지만 그나마 동작했고, 자동화된 해법은 근처에도 못 왔음
    좋은 HA 스토리가 부족해서 자체 운영 Postgres는 가능한 피하게 됨

    • 우리도 HA를 지원함: https://docs.pgdog.dev/features/load-balancer/
      상태 확인과 장애 조치가 있는 로드 밸런서가 기본으로 동작하고, 이제 충분히 실전 검증도 되었으니 살펴볼 만함
    • Patroni 1.0은 2016년에 나왔으니 거의 10년 전임
      https://github.com/patroni/patroni
    • cnpg를 써봤는지 궁금함
      내 용도에서는 정말 잘 동작했음
    • 지금은 Patroni가 이 영역을 꽤 잘 해결해 줌
    • CloudNativePG 같은 것도 살펴봤는지 궁금함: https://cloudnative-pg.io/

  • “Why Us”에 “Instacart에서 Postgres를 운영했고, 2020년 4월 회사가 5배로 커질 때 Postgres가 분당 수십만 건의 식료품 배송 주문을 처리하게 만드는 게 가장 큰 문제였다”고 쓰여 있다면, 이보다 더 좋은 왜 우리인가는 없을 듯함

    • 분당 10만 주문이 많은 건가?
      Postgres 인스턴스 하나로도 충분히 처리할 수 있어 보임
    • 왜 기준을 분당으로 바꿨는지 궁금함
      현대적인 고품질 엔터프라이즈 SSD는 초당 3.5만 회 안팎의 실제 fsync를 처리할 수 있음
    • Instacart는 항상 엄청 느리고 지연 시간이 컸다고 느꼈음
      물론 그게 Postgres 때문인지 다른 설계 결함 때문인지는 모름

  • 기본적으로 이해해보고 싶은데, 지금은 큰 서버 한 대에 4TB DB가 있음
    PGDog 같은 프록시 도구를 쓰면 약 500GB씩 맡는 작은 서버 8대를 띄우고, 프록시용 중간급 서버 1대를 두는 구조가 되는 건지 궁금함
    현재 프로젝트는 여러 서비스에서 쓰기 트래픽이 매우 많고, 웹 앱이 여기서 읽어 감
    이제 인덱싱, 쿼리 최적화, 캐싱, 서버 업그레이드를 아무리 해도 도움이 안 되는 지점에 가까워지고 있음
    정적 데이터의 대부분을 ClickHouse로 옮겨 DB 크기를 줄이는 방안도 보고 있지만, PgDog나 다른 샤딩이 이런 용도에 유용할지 듣고 싶음

    • “약 500GB씩 맡는 작은 서버 8대와 프록시용 중간급 서버 1대”가 정확히 그 구조임
      연락 주면 좋겠음(lev@pgdog.dev)
      도와주거나 최소한 현재 무엇이 동작하고 무엇이 안 되는지 알려줘서 선택지를 파악할 수 있게 해줄 수 있음
    • 그게 샤딩의 개념임
      pgdog 문서를 읽어보면 요청을 어느 샤드 서버로 라우팅할지 알려줘야 한다는 걸 볼 수 있고, 마법처럼 그냥 동작하지는 않음
      그래도 Postgres에서 특히 비싼 연결을 재사용해 주기 때문에 가치는 있음
      마법이 아니므로 내부에서 무슨 일이 일어나는지 알아야 하고, 예를 들어 샤드 간 트랜잭션은 없음
      샤딩은 데이터 일관성을 신경 쓴다면 어렵기 때문에, 먼저 애플리케이션이 읽기 복제본으로 이득을 볼 수 있는지 보겠음
      복제본은 각각 전체 데이터 사본을 갖고 쓰기는 마스터에만 하며, 거의 실시간보다 약간 뒤처질 수 있는 복제본에서 실행해도 되는 트랜잭션을 직접 판단해야 함
      예를 들어 웹페이지를 만들기 위한 읽기는 복제본에서 해도 대체로 안전하지만, 읽기-수정-쓰기는 그렇지 않음

  • Postgres에서 가장 큰 다운타임 원인인 메이저 버전 업그레이드에 이게 어떻게 도움이 될지 궁금함
    풀러는 장애 조치와 부하 분산에는 훌륭하지만, 업그레이드 때문에 1년에 한두 번씩 꾸준히 10~20분 정도 다운타임이 필요함
    구버전에서 신버전으로의 논리 복제가 도움이 될 수는 있겠지만, 부분 쓰기나 이상한 상태 없이 모든 것을 새 클러스터로 넘기는 작업은 여전히 필요할 듯함
    이런 경험이 있는지 궁금함

    • 우리는 논리 복제와 pgbouncer의 일시 정지/전환을 써서 쓰기가 실패하지 않고 약 5초 정도 멈추게 함
      DB 크기는 약 1~1.5TB지만 변경량이나 초당 쿼리 수가 엄청 많지는 않음
      사실상 여기서 설명한 방식임: https://www.pgedge.com/blog/always-online-or-bust-zero-downt...
    • 보통은 논리 복제로 처리함
      코드형 인프라 구성이 있다면 메이저 버전만 다르고 설정은 동일한 새 클러스터를 만들고, 스키마를 가져온 뒤, 구버전 읽기 복제본에서 데이터 복사를 시작하고, 구버전 쓰기 수락을 멈춘 다음(다운타임 시작), 시퀀스 번호를 동기화하고, 서비스를 새 클러스터로 향하게 함(다운타임 종료)
      CloudNativePG 같은 걸 쓰면 CLI 도구와 선언적 문법으로 이 과정 일부를 자동화해 줌
      아니면 직접 시간을 들여 파악해야 함
      복잡하게 들릴 수 있지만 스테이징 DB에서 연습한 뒤 잘 되면 운영에서도 같은 절차를 하면 됨
      추가로 Postgres 19에는 시퀀스의 일회성 논리 복제를 위한 패치가 있는 듯함: https://www.depesz.com/2025/11/11/waiting-for-postgresql-19-...
    • 논리 복제가 이걸 해결함
      클러스터를 순차적으로 굴리면 다운타임은 매우 작고, 대략 60초 정도일 수 있음
    • PostgreSQL에 아직 제대로 된 오픈소스 범용 다중 마스터 구현이 없다는 게 이상함
      이쯤 되면 내가 언젠가 보긴 할지 의문임
    • MySQL에서 오면 이건 큰 퇴보이고, Postgres가 80년대 물건처럼 보이게 만듦
      왜 이게 절대 최우선순위로 여겨지지 않는지 아직도 궁금함

  • 펀딩 축하함, Lev
    여기서는 PgDog를 만족스럽게 쓰고 있음
    프록시 기능 중 연결별로 서로 다른 연결 설정, 예를 들어 statement_timeout을 처리하는 점을 꽤 좋아함
    예전에 RDS Proxy를 조사했을 때는 지원하지 않았고, pgbouncer도 마찬가지였던 것 같아서 애플리케이션 변경이 많이 필요했음
    PgDog에서는 투명하게 그냥 동작함

  • 방금 발표된 Supabase의 multigres와 비교할 만한 건지 궁금함

  • Enterprise Edition이 보이는데, 어떤 기능이 오픈소스가 아닌지 명확히 알려줄 수 있는지 궁금함
    새로 추가하는 기능들이 VC 투자자에게 보답하기 위해 EE 라이선스가 될 거라고 예상하는지도 궁금함

    • 큰 기능은 두 가지임
      첫째, 다중 노드 배포를 관리하는 컨트롤 플레인으로, PgDog를 쉽게 배포하고 사용할 수 있게 “바로 동작하는” 경험을 제공함
      둘째, 서비스 품질(QoS)로, 나쁜 쿼리가 데이터베이스를 다운시키지 못하게 자동 차단함
      마지막으로 P0까지 SLA가 보장되는 지원을 받을 수 있음
      새 기능은 두 범주로 나뉨
      샤딩과 대규모 Postgres 운영은 항상 오픈소스이고, 인프라 관리와 PgDog를 대규모로 쉽게 운영하게 만드는 기능은 엔터프라이즈임

  • PgDog, Neki, multigres가 나오는 건 보기 좋음
    맞게도 이게 Postgres의 핵심 문제이고, 여기에 인덱스 힌트가 없는 것도 문제라 Postgres 19가 기대됨

    • 원조인 PgBouncer도 잊으면 안 됨
      설정이 어렵지만 요즘은 AI 도움으로 구성하기가 쉬워짐
    • pg_hint_plan 확장은 코어에 들어가 있지는 않지만, 플래너를 재정의해야 할 때 꽤 유능함

  • “우리가 아는 것만 20TB 넘게 샤딩했다”는 아마 오타일 듯함
    20TB는 그렇게 크지 않음
    훨씬 더 많이 샤딩했을 거라고 생각함

    • 20TB가 “그렇게 크지 않다”고 생각한다면 어떤 크기의 DB를 다루는지 알고 싶음
    • 작업 집합이 20TB라면 꽤 큼
      데이터베이스마다 뜨거운 데이터와 차가운 데이터의 비율이 달라서 더 많은 정보 없이는 비교가 불가능함
      더 나은 척도는 IOPS일 수 있음
      RDS는 프로비저닝 IOPS에 훨씬 더 많은 비용을 쓰거나 Aurora를 쓰지 않으면 최대 IOPS가 꽤 낮음
    • 맞음
      비교하자면 거의 10년 전 Segment에서 약 50TB 데이터를 가진 단일 Aurora PostgreSQL 인스턴스를 운영했는데, S3에 저장된 훨씬 더 큰 파일 말뭉치 안에서 잠재적 식별자 데이터를 인덱싱하는 데 쓰였음
    • 대다수 사용 사례에서 20TB는 확실히 거대함

  • PgDog가 좋음
    솔직히 필요하진 않지만, 숲에서 하이킹하다 들을 게 없어 Postgres FM 팟캐스트를 우연히 들었고 흥미가 생겨서 내 온프레미스 Kubernetes에서 쓰고 있음
    https://open.spotify.com/episode/6qgpfiW68KcvRASs6649Fb

답변달기