Postgres 샤딩 운영 2026, Citus·Multigres 도입 전 성능·비용·장애 기준
Postgres 샤딩은 노드 수보다 shard key, 백업, 장애 복구, 비용 리뷰가 먼저다. Postgres 샤딩 운영을 검토하는 팀은 보통 “서버를 더 크게 올릴지, 여러 노드로 나눌지”의 갈림길에 서 있다. 단일 primary의 CPU와 I/O가 막히고, 가장 큰 테이블이 메모리 창을 넘어가며, 특정 tenant나 region이 전체 성능을 끌어내릴 때 이 질문이 나온다. Supabase가 공개한 Multigres v0.1 alpha는 Postgres에 Vitess식 수평 확장, HA, pooling, backup orchestration을 가져오려는 시도다. 다만 해당 발표는 v0.1이 production workload용이 아니고, 핵심 샤딩 기능도 이번 릴리스에는 없다고 분명히 적었다. 그래서 이 글은 Multigres 발표를 새 도구 소개로 옮기지 않는다. Postgres 샤딩 운영을 실제로 시작하기 전, Citus 계열 분산 Postgres, PostgreSQL 파티셔닝, postgres_fdw, 복제, 백업, 모니터링을 어떤 순서로 비교해야 하는지 정리한다. 결론부터 말하면 shard key를 설명하지 못하면 아직 샤딩 단계가 아니다. 쿼리 패턴, 장애 복구 시간, cross-shard 비율, rebalance 방식, 백업 복원 시간을 숫자로 확인한 뒤에야 노드를 늘릴 자격이 생긴다. 핵심 요약 Postgres 샤딩 운영은 단일 DB 튜닝의 연장이 아니라 애플리케이션 라우팅, 트랜잭션 경계, 장애 복구가 바뀌는 프로젝트다. Citus·Elastic Clusters는 row-based 또는 schema-based sharding을 제공하지만, distribution column 선택이 성능과 기능을 좌우한다. PostgreSQL 기본 partitioning은 한 서버 안의 데이터 수명주기와 pruning에 강하고, 여러 노드 write scale-out을 자동으로 해결하지 않는다. Multigres v0.1 alpha는 HA와...
