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

“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분 정도 다운타임이 필요함
구버전에서 신버전으로의 논리 복제가 도움이 될 수는 있겠지만, 부분 쓰기나 이상한 상태 없이 모든 것을 새 클러스터로 넘기는 작업은 여전히 필요할 듯함
이런 경험이 있는지 궁금함

보통은 논리 복제로 처리함
코드형 인프라 구성이 있다면 메이저 버전만 다르고 설정은 동일한 새 클러스터를 만들고, 스키마를 가져온 뒤, 구버전 읽기 복제본에서 데이터 복사를 시작하고, 구버전 쓰기 수락을 멈춘 다음(다운타임 시작), 시퀀스 번호를 동기화하고, 서비스를 새 클러스터로 향하게 함(다운타임 종료)
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에 저장된 훨씬 더 큰 파일 말뭉치 안에서 잠재적 식별자 데이터를 인덱싱하는 데 쓰였음