# PgDog이 투자 유치를 완료하고 가까운 데이터베이스로 찾아옵니다
> Clean Markdown view of GeekNews topic #30397. Use the original source for factual precision when an external source URL is present.
## Metadata
- GeekNews HTML: [https://news.hada.io/topic?id=30397](https://news.hada.io/topic?id=30397)
- GeekNews Markdown: [https://news.hada.io/topic/30397.md](https://news.hada.io/topic/30397.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-11T18:37:12+09:00
- Updated: 2026-06-11T18:37:12+09:00
- Original source: [pgdog.dev](https://pgdog.dev/blog/our-funding-announcement)
- Points: 1
- Comments: 1
## Topic Body
- **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](https://discord.gg/CcBZkjSJdd) 커뮤니티가 성장 중이며, 매일 질문 응답과 지원이 이뤄짐
- ## 팀과 신뢰 근거
- 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](https://pgdog.dev/enterprise)은 AWS에서 더 쉽게 실행할 수 있도록 개발 중임
- Enterprise edition은 팀의 SLA 기반 지원을 제공함
## Comments
### Comment 59425
- Author: neo
- Created: 2026-06-11T18:37:13+09:00
- Points: 1
###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48476466)
- 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]()