Postgres 샤딩 운영 2026, Citus·Multigres 도입 전 성능·비용·장애 기준
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와 pooling 실험 신호로 볼 수 있지만, 샤딩 production 도입 근거로 바로 쓰면 안 된다.
이 글이 필요한 사람
- 단일 PostgreSQL primary가 커졌지만 샤딩 전 마지막 튜닝 기준을 정하지 못한 DBA
- Citus, Azure Database for PostgreSQL Elastic Clusters, Multigres 같은 분산 Postgres 선택지를 비교하는 플랫폼 팀
- tenant_id, region_id, account_id 중 어떤 shard key가 안전한지 검토해야 하는 백엔드 리드
- 복제 지연, 백업 복원, cross-shard query 비용을 운영 지표로 설명해야 하는 SRE
- 데이터 플랫폼 비용을 줄이려다 장애 복구와 보안 통제를 놓칠까 걱정하는 CTO 또는 인프라 책임자
1. 샤딩 전에 단일 Postgres 병목을 먼저 증명한다
샤딩은 성능 튜닝 버튼이 아니다.
애플리케이션이 데이터를 찾는 경로, 트랜잭션 경계, 배포 절차, 장애 대응 순서가 바뀌는 구조 변경이다.
PostgreSQL 공식 문서는 partitioning이 큰 테이블을 작은 물리 조각으로 나눠 특정 쿼리와 bulk load, bulk delete, 오래된 데이터 이동에 이점을 줄 수 있다고 설명한다.
이 설명은 단일 서버 안에서도 먼저 할 수 있는 작업이 많다는 뜻이다.
샤딩 후보를 올리기 전에는 가장 큰 테이블, 가장 비싼 쿼리, 가장 뜨거운 tenant, autovacuum 지연, WAL 증가, connection pool 대기 시간을 한 장의 표로 모아야 한다.
이 표가 없으면 분산 구조로 옮긴 뒤에도 병목은 이름만 바뀐다.
| 확인 항목 | 샤딩 전 질문 | 단일 DB에서 먼저 할 일 | 샤딩 검토 신호 |
|---|---|---|---|
| 큰 테이블 | 테이블 크기가 메모리와 백업 시간을 압박하는가 | partitioning, index 재설계, archive 정책 | 테이블 하나가 서비스 전체 write 경로를 막는다 |
| 핫 키 | 특정 tenant나 region이 전체 부하를 만든는가 | rate limit, tenant별 쿼리 분리 | 상위 1% key가 대부분의 I/O를 차지한다 |
| 트랜잭션 | 여러 tenant를 한 transaction에서 같이 갱신하는가 | 업무 경계 재설계, outbox 패턴 검토 | cross-shard transaction이 핵심 경로가 아니다 |
| 읽기 부하 | read replica로 충분한가 | hot standby, query routing, cache | write primary가 먼저 한계에 닿는다 |
| 운영 시간 | 백업과 restore가 SLO를 넘는가 | PITR, dump 분리, restore rehearsal | 단일 cluster 복원이 허용 시간을 반복 초과한다 |
이 조건이면 샤딩 검토가 맞다.
단일 primary write가 막히고, vertical scale 비용이 급격히 커지며, shard key 후보로 트래픽을 안정적으로 나눌 수 있을 때다.
이 경우는 보류한다.
쿼리 계획이 망가졌거나 autovacuum이 밀렸거나 connection pool이 과하게 열려 있는 문제라면 분산 DB보다 기본 운영 정리가 먼저다.
2. partitioning, read replica, FDW, Citus를 같은 해법으로 보지 않는다
PostgreSQL declarative partitioning은 range, list, hash 방식으로 한 논리 테이블을 여러 partition으로 나눈다.
쿼리 pruning, 데이터 보존 기간 관리, bulk delete에는 강하지만 여러 서버에 write를 자동 분산하는 샤딩과는 다르다.
postgres_fdw는 외부 PostgreSQL 서버의 데이터를 foreign table로 접근하게 한다.
공식 문서는 remote server, user mapping, foreign table을 만들고 SELECT뿐 아니라 INSERT, UPDATE, DELETE 같은 수정도 가능하다고 설명한다.
Citus 계열의 Elastic Clusters는 여러 PostgreSQL 노드를 shared nothing architecture로 묶고, distributed table을 worker node의 shard에 저장한다.
Microsoft 문서는 coordinator가 query를 관련 worker에 route하거나 여러 worker에 병렬화한다고 설명한다.
| 선택지 | 해결하는 문제 | 해결하지 못하는 문제 | 운영 난이도 |
|---|---|---|---|
| Declarative partitioning | 큰 테이블 pruning, 보존 기간, bulk delete | 여러 노드 write scale-out | 중간 |
| Read replica | 읽기 부하 분산, 분석 쿼리 분리 | primary write 병목 | 중간 |
| postgres_fdw | 원격 Postgres 접근, migration bridge, 일부 federation | 투명한 OLTP 샤딩 | 높음 |
| Citus·Elastic Clusters | row/schema based sharding, worker 병렬 처리 | 나쁜 distribution column과 cross-shard 설계 | 높음 |
| Multigres alpha | HA, pooling, backup orchestration 실험 | v0.1 기준 production sharding | 실험 단계 |
실무 시나리오 하나.
주문 테이블이 날짜 기준으로만 커지고 최근 90일 쿼리가 대부분이면 partitioning과 archive가 먼저다.
이 구조에서 바로 Citus로 가면 애플리케이션 복잡도만 늘 수 있다.
실무 시나리오 둘.
tenant별 데이터가 명확히 분리되고, 대부분의 쿼리가 tenant_id 조건을 가진다면 row-based sharding 후보가 된다.
이때 cross-tenant 리포트는 별도 분석 파이프라인으로 빼는 편이 안전하다.
3. shard key 선택은 성능보다 장애 범위를 정하는 결정이다
샤딩 프로젝트에서 가장 큰 비용은 노드가 아니라 잘못 고른 shard key다.
distribution column이 쿼리 조건에 없으면 coordinator가 여러 worker를 뒤지고, 특정 key가 너무 크면 한 shard만 계속 뜨거워진다.
Elastic Clusters 문서는 row-based sharding에서 distribution column이 row를 shard에 배정하는 기준이라고 설명한다.
이 컬럼 선택이 성능과 기능에 중요하다고 명시한 이유가 여기에 있다.
| 후보 shard key | 좋은 조건 | 위험 조건 | 판단 |
|---|---|---|---|
| tenant_id | 대부분의 OLTP 쿼리가 tenant 단위로 닫힌다 | 대형 tenant 몇 개가 전체 부하를 만든다 | SaaS multi-tenant에 가장 먼저 검토 |
| region_id | 지역별 데이터와 운영 조직이 분리된다 | 특정 수도권 region이 압도적으로 크다 | 규제·지연 요구가 있을 때만 신중히 선택 |
| account_id | 계정 단위 트랜잭션이 명확하다 | 조직 계층과 결제 단위가 자주 바뀐다 | 업무 경계가 안정적이면 가능 |
| created_at | 수명주기와 보관 정책이 핵심이다 | 최근 데이터가 한 shard에 몰린다 | 샤딩보다 partitioning에 가까운 선택 |
| hash(order_id) | 분포는 고르지만 라우팅 조건이 단순하다 | 주문 조회 외 join과 집계가 많다 | 쓰기 분산은 좋지만 업무 조회 비용을 봐야 한다 |
좋은 shard key는 고르게 나누는 컬럼이 아니라 자주 같이 읽고 쓰는 데이터를 같은 위치에 둔다.
분포만 보고 고르면 join과 transaction이 매번 네트워크를 탄다.
조건부 판단은 명확하다.
shard key 조건이 없는 핵심 쿼리가 20%를 넘는다면 먼저 API와 쿼리 모델을 바꿔야 한다.
분산 엔진을 넣어도 cross-shard query 비용은 사라지지 않는다.
4. Citus·Elastic Clusters 운영은 coordinator와 worker 장애를 따로 본다
Elastic Clusters는 coordinator와 worker가 있는 shared nothing 구조를 설명한다.
애플리케이션은 coordinator로 접속하고, coordinator는 metadata를 보고 필요한 worker로 query를 보낸다.
이 구조는 단일 primary보다 확장 여지가 크지만 장애 지점도 달라진다.
coordinator 장애, worker 장애, metadata 불일치, rebalance 지연, shard placement 문제가 각각 다른 runbook을 요구한다.
| 장애 지점 | 사용자가 보는 증상 | 먼저 볼 지표 | 운영 조치 |
|---|---|---|---|
| Coordinator | 모든 요청 지연 또는 접속 실패 | connection count, CPU, lock, query queue | failover 경로와 app connection string 검증 |
| Worker hot shard | 특정 tenant만 느림 | shard별 QPS, p95, disk I/O | rebalance 또는 tenant split 검토 |
| Cross-shard query | 리포트와 join 쿼리만 느림 | task fan-out, network time, temp file | OLTP와 analytics 경로 분리 |
| Rebalance | 노드 추가 중 지연과 lock 증가 | rebalance progress, WAL, replication lag | 피크 시간 회피와 rollback 기준 설정 |
| Backup/restore | 복구 시간이 예측보다 길다 | shard별 backup size, restore duration | 정기 restore rehearsal와 우선순위 정리 |
실무 시나리오 셋.
결제 API는 tenant_id 조건으로 빠르지만 월말 정산 리포트가 전체 tenant를 훑는다.
이 경우 OLTP cluster에 리포트 쿼리를 계속 넣지 말고 logical replication이나 ETL로 분석 저장소를 분리한다.
운영팀이 처음 만들어야 할 대시보드는 노드별 CPU 그래프가 아니다.
coordinator queue, shard별 p95, hot key 순위, cross-shard query rate, replication lag, rebalance status를 한 화면에 둬야 한다.
5. Multigres는 신호로 보되 production 샤딩 근거로 보지 않는다
Supabase의 Multigres v0.1 alpha 발표는 Postgres 운영 복잡도를 하나의 시스템으로 묶으려는 방향을 보여준다.
발표 내용에는 connection pooling, automatic failover, Kubernetes operator, backup orchestration이 포함된다.
하지만 발표 자체가 더 중요한 경고도 함께 준다.
v0.1은 실험과 피드백을 위한 alpha이고, sharding은 이번 릴리스에 없으며, future release의 backward compatibility도 보장되지 않는다고 적었다.
| Multigres 항목 | 발표에서 확인되는 점 | 운영 해석 | 도입 판단 |
|---|---|---|---|
| Kubernetes Operator | Kubernetes cluster와 backup location을 전제로 cluster를 배포 | DB 운영이 Kubernetes 운영과 결합된다 | DBA와 플랫폼팀 공동 소유 필요 |
| HA protocol | Postgres replication 위에서 consensus 문제로 다룸 | failover 정책을 도구에 맡겨도 검증은 필요 | RPO/RTO 리허설 전 production 금지 |
| Connection pooling | multigateway와 multipooler 구조 | 장애 중 routing과 pool state가 핵심 지표 | pool 대기 시간과 pinning을 관측 |
| Backups | pgBackRest 기반 replica backup 설명 | primary 부담 완화 가능성은 있으나 restore 검증이 핵심 | 복원 시간 측정 전 확대 금지 |
| Sharding | v0.1에는 없음 | 샤딩 운영 글의 참고 신호일 뿐 | production shard engine처럼 쓰지 않음 |
이 조건이면 Multigres를 실험할 만하다.
비운영 데이터, 작은 Kubernetes test cluster, restore rehearsal, 장애 재현 시간을 확보했고, alpha API 변경을 감당할 팀이 있을 때다.
이 경우는 보류한다.
production 고객 데이터, 규제 데이터, 24시간 결제 경로, DBA 없는 플랫폼팀 환경이라면 Citus나 managed Postgres 선택지와 기본 HA부터 검토해야 한다.
6. 비용 구조는 노드 수보다 데이터 이동과 관측에서 터진다
Postgres 샤딩 운영 비용은 compute node 가격만으로 계산하면 틀린다.
shard별 storage, backup storage, cross-node network, rebalance 시간, connection pool, monitoring metric, 로그 보존까지 같이 봐야 한다.
PostgreSQL monitoring statistics 문서는 server activity, table/index access, vacuum/analyze, current command, connection 상태 등을 확인하는 view를 제공한다고 설명한다.
분산 구조에서는 이 통계가 노드별로 흩어지므로 수집 방식도 설계해야 한다.
| 비용 항목 | 샤딩 후 늘어나는 이유 | 측정 지표 | 줄이는 방법 |
|---|---|---|---|
| Compute | coordinator와 worker가 최소 단위로 늘어난다 | node CPU, memory, idle time | hot shard만 보고 무작정 전체 증설 금지 |
| Storage | shard, replica, index, backup이 분산 저장된다 | shard별 size, index bloat | archive와 partition detach 정책 |
| Network | cross-shard join과 rebalance가 노드 간 traffic을 만든다 | cross-node bytes, query fan-out | query model 분리와 reference table 활용 |
| Monitoring | 노드별 metric과 log cardinality가 늘어난다 | metric count, log GiB, slow query volume | 핵심 지표 중심 dashboard와 retention 제한 |
| 운영 인력 | 장애 원인 분리가 어려워진다 | incident time, rollback time, on-call count | runbook과 rehearsal 자동화 |
비용 절감이 목표라면 먼저 큰 tenant와 리포트 workload를 분리한다.
모든 데이터를 샤딩하는 것보다 hot tenant isolation, archive partition, read replica, cache가 더 싸게 끝나는 경우가 많다.
반대로 availability가 목표라면 비용표만 보면 안 된다.
단일 primary 장애가 매출과 SLA를 크게 흔든다면 standby, failover rehearsal, backup restore 시간을 먼저 줄여야 한다.
7. 보안과 권한은 shard 수만큼 복잡해진다
postgres_fdw 공식 문서는 user mapping에 remote user와 password를 지정하고, 일부 인증 옵션은 superuser만 다룰 수 있다고 설명한다.
이 내용은 분산 Postgres에서 권한 관리가 단순하지 않다는 신호다.
샤딩 이후에는 애플리케이션 role, DBA role, replication role, backup role, migration role이 서로 다른 노드와 metadata에 접근한다.
하나의 superuser로 모든 작업을 처리하면 장애 때 원인 추적이 무너진다.
| 권한 영역 | 허용 기준 | 금지 기준 | 감사 포인트 |
|---|---|---|---|
| Application role | 필요 schema와 DML만 허용 | DDL, superuser, replication 권한 | role change, grant history |
| Shard admin | break-glass와 승인 기록 | 개인 계정 상시 admin | 작업 사유와 ticket |
| FDW mapping | rotation 가능한 전용 계정 | 공유 password와 public mapping | user mapping scope |
| Backup role | backup 대상과 restore 권한 분리 | production write 권한 포함 | restore rehearsal log |
| Migration role | DDL window와 rollback 계획 | 업무 시간 무제한 schema 변경 | DDL audit와 lock time |
실무 시나리오 넷.
고객별 schema-based sharding을 쓰면 테넌트 격리는 쉬워 보인다.
그러나 운영자가 전체 schema를 조회하는 admin 기능을 만들 때 권한과 감사 로그를 다시 설계하지 않으면 내부자 접근 범위가 커진다.
보안팀에 설명할 문장은 간단해야 한다.
“샤드가 늘어도 애플리케이션은 최소 권한으로만 접속하고, shard metadata와 DDL은 DBA break-glass로만 다룬다”를 정책으로 고정한다.
8. 백업과 복원은 샤딩 승인 전 실제로 재본다
PostgreSQL backup 문서는 SQL dump, file system level backup, continuous archiving이라는 세 가지 기본 접근을 제시한다.
샤딩 환경에서는 이 선택지가 노드 수와 shard 수만큼 복잡해진다.
복구 전략은 “백업이 있다”가 아니라 “어떤 shard를 어떤 시점으로 얼마나 빨리 되돌릴 수 있는가”로 적어야 한다.
특히 부분 장애와 전체 장애의 runbook을 분리해야 한다.
| 복구 시나리오 | 확인 질문 | 측정할 숫자 | 중단 기준 |
|---|---|---|---|
| 단일 shard 손상 | 해당 tenant만 되돌릴 수 있는가 | target shard restore minutes | 다른 tenant까지 멈추면 실패 |
| Worker 장애 | replica promote와 routing 변경이 검증됐는가 | RTO, replication lag | manual step이 30분 이상이면 보류 |
| Coordinator 장애 | metadata와 connection path를 복구할 수 있는가 | failover time, app reconnect time | connection string 전파가 수동이면 위험 |
| 잘못된 DDL | 모든 shard의 schema rollback이 가능한가 | lock time, rollback time | 부분 적용 상태가 남으면 실패 |
| 대규모 restore | 전체 cluster를 새 환경에 복원할 수 있는가 | full restore hours, data validation time | 리허설 없는 production 확대 금지 |
샤딩 승인 회의에서 가장 먼저 물을 질문은 “몇 노드까지 늘릴 수 있나”가 아니다.
“가장 큰 shard 하나를 어제 15시 상태로 되돌리는 데 몇 분 걸렸나”가 더 실무적이다.
이 질문에 답하지 못하면 아직 production 샤딩이 아니다.
기능 데모는 성공했어도 운영은 실패할 수 있다.
9. Postgres 샤딩 운영 정책 스켈레톤
아래 YAML은 실제 배포 파일이 아니라 도입 승인 체크리스트다.
플랫폼팀, DBA, 백엔드팀, 보안팀이 같은 언어로 위험을 확인하게 만드는 목적이다.
# postgres-sharding-operating-policy.yaml
# 목적: Postgres 샤딩 운영 검토를 기능 데모가 아니라 성능, 장애, 비용, 보안 기준으로 승인한다.
# 실제 수치와 소유자는 조직의 SLO, 예산, 데이터 등급에 맞게 수정한다.
service:
name: order-platform
data_owner: commerce-data
db_owner: platform-dba
business_slo: checkout_p95_under_300ms
data_classification: internal-and-customer-data
sharding_decision:
current_blocker:
- single_primary_write_saturation
- largest_table_exceeds_memory_window
- tenant_or_region_hotspot
reject_if:
- no_stable_shard_key
- cross_shard_transaction_is_core_path
- backup_restore_runbook_missing
- app_team_cannot_handle_dual_write_or_routing_changes
preferred_model:
- row_based_for_multi_tenant_same_schema
- schema_based_for_tenant_isolation
- native_partitioning_for_lifecycle_and_pruning_only
operations:
must_measure:
- p95_query_latency_by_shard_key
- cross_shard_query_rate
- hottest_shard_ratio
- replication_lag_seconds
- rebalance_duration_minutes
- backup_restore_time_minutes
- connection_pool_wait_ms
monthly_cost_review:
- node_count
- storage_per_shard
- backup_storage
- network_egress_between_nodes
- monitoring_metric_count
security:
shard_admin_role: dba-break-glass-only
application_role: no-ddl-no-superuser
fdw_user_mapping: password-rotation-required
audit_log: ddl-and-role-change
pii_policy: shard_key_must_not_expose-sensitive-id-directly
다음 SQL은 샤딩 전 점검용 예시다.
실제 운영 DB에서는 권한, 부하, 개인정보 정책을 확인한 뒤 read-only replica나 점검 계정에서 먼저 실행한다.
-- postgres_shard_review.sql
-- 목적: 샤딩 전후에 단일 DB 병목과 분산 DB 위험 신호를 같은 표로 점검한다.
-- 운영 DB에 바로 적용하기 전, read-only replica 또는 점검 계정에서 먼저 검증한다.
-- 1) 큰 테이블과 인덱스 비율 확인
SELECT
schemaname,
relname,
n_live_tup,
pg_size_pretty(pg_total_relation_size(relid)) AS total_size,
pg_size_pretty(pg_relation_size(relid)) AS table_size,
last_vacuum,
last_autovacuum,
last_analyze,
last_autoanalyze
FROM pg_stat_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 20;
-- 2) 후보 shard key의 분포 편향 확인 예시
-- tenant_id, created_at, order_id 같은 후보 컬럼을 실제 컬럼명으로 바꾼다.
SELECT
tenant_id,
count(*) AS rows,
round(100.0 * count(*) / sum(count(*)) OVER (), 2) AS pct
FROM orders
GROUP BY tenant_id
ORDER BY rows DESC
LIMIT 20;
-- 3) 파티션 pruning이 실제로 되는지 실행 계획으로 확인
EXPLAIN (ANALYZE, BUFFERS)
SELECT count(*)
FROM orders
WHERE created_at >= now() - interval '7 days'
AND tenant_id = 1001;
-- 4) 복제 지연과 slot 위험 확인
SELECT
application_name,
state,
sync_state,
write_lag,
flush_lag,
replay_lag
FROM pg_stat_replication;
SELECT
slot_name,
slot_type,
active,
pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal
FROM pg_replication_slots;
이 스켈레톤의 핵심은 자동화가 아니라 중단 기준이다.
shard key가 불안정하거나 backup restore runbook이 없으면 도구가 무엇이든 production 진행을 멈춘다.
10. 발행 전 실행 순서와 보류 기준
Postgres 샤딩 운영 프로젝트는 PoC, 파일럿, production migration을 분리해야 한다.
PoC에서 쿼리가 빨라졌다는 결과만으로 production 전환을 승인하면 장애 때 되돌릴 경로가 없다.
- 가장 큰 테이블 20개와 가장 비싼 쿼리 20개를 뽑고, 샤딩 없이 해결 가능한 항목을 먼저 지운다.
- 후보 shard key별 row 분포, top key 비율, 핵심 쿼리의 shard key 조건 포함률을 계산한다.
- partitioning, read replica, FDW, Citus·Elastic Clusters, Multigres 실험을 같은 표에서 비교한다.
- cross-shard transaction과 cross-shard query가 사용자 경로에 얼마나 있는지 측정한다.
- 백업, restore, failover, rebalance를 staging 데이터로 실제 실행하고 시간을 기록한다.
- application connection string, pooler, migration tool, CI 권한, DBA break-glass 권한을 분리한다.
- 파일럿 tenant나 낮은 위험 workload를 골라 shard별 p95, error, cost, incident time을 2주 이상 본다.
- 기준을 통과하면 다음 tenant 또는 workload로 확장하고, 통과하지 못하면 단일 DB 튜닝이나 읽기 분리로 돌아간다.
보류 기준도 숫자로 둔다.
hottest shard가 전체 row의 30%를 넘고, 핵심 쿼리의 shard key 조건 포함률이 낮고, restore rehearsal이 SLO를 넘으면 production migration을 멈춘다.
승인 기준은 반대다.
shard key 분포가 안정적이고, cross-shard 비율이 설명 가능하며, failover와 restore가 반복 측정됐고, 비용 증가분을 예산표로 설명할 수 있으면 다음 단계로 간다.
함께 보면 좋은 글
Postgres 샤딩은 데이터 플랫폼, 로그 비용, 서비스 모니터링, 클라우드 비용, 쿠버네티스 운영과 같이 봐야 판단이 정확하다.
데이터 플랫폼 구축 2026, 도입 전 비용·성능·운영 기준
로그 모니터링 비용 2026, 수집·보관·조회 비용 줄이는 운영 기준
서비스 모니터링 도구 2026, 장애 대응 전 비용·알림·로그 기준
클라우드 비용 최적화 2026, AWS 비용 줄이기 전 확인할 운영 기준
쿠버네티스 운영 비용 2026, 클러스터·노드·로그 비용 줄이는 기준자주 묻는 질문
Postgres 샤딩 운영은 언제 시작해야 하나요?
단일 primary write 병목이 반복되고, vertical scale 비용이 과해지며, 안정적인 shard key 후보가 있을 때 시작한다.
단순히 테이블이 크다는 이유만으로 샤딩하면 운영 복잡도가 먼저 커진다.
PostgreSQL partitioning과 샤딩은 같은 뜻인가요?
같지 않다.
partitioning은 보통 한 서버 안에서 테이블을 나눠 pruning, bulk delete, 보존 정책을 다루는 기능이다.
샤딩은 여러 노드에 데이터를 나눠 쓰기와 저장 용량을 분산하는 운영 구조에 가깝다.
Citus를 쓰면 shard key 문제를 자동으로 해결하나요?
아니다.
Citus 계열 도구가 routing과 분산 실행을 제공해도 distribution column 선택은 사용자가 해야 한다.
핵심 쿼리가 shard key를 포함하지 않으면 cross-shard 비용은 그대로 남는다.
Multigres v0.1 alpha를 production에 써도 되나요?
공개 발표 기준으로 v0.1은 production workload용이 아니고 샤딩 기능도 이번 릴리스에 없다.
비운영 실험과 방향성 검토에는 의미가 있지만 production 샤딩 근거로 삼으면 안 된다.
샤딩 후 백업은 어떻게 달라지나요?
노드와 shard 수만큼 복원 단위가 복잡해진다.
전체 cluster 복구뿐 아니라 특정 shard, 특정 tenant, 특정 시점 복원 시간을 별도로 재야 한다.
샤딩 대신 read replica로 해결할 수 있는 경우는 언제인가요?
읽기 쿼리가 병목이고 primary write는 여유가 있다면 read replica, cache, 리포트 분리부터 검토한다.
write path와 hot tenant가 문제일 때만 샤딩 검토 가치가 커진다.
출처와 확인일
- Supabase Blog — Multigres v0.1 Alpha: an operating system for Postgres (확인일: 2026-07-02)
- PostgreSQL Docs — Table Partitioning (확인일: 2026-07-02)
- PostgreSQL Docs — postgres_fdw — access data stored in external PostgreSQL servers (확인일: 2026-07-02)
- PostgreSQL Docs — High Availability, Load Balancing, and Replication (확인일: 2026-07-02)
- PostgreSQL Docs — Logical Replication (확인일: 2026-07-02)
- PostgreSQL Docs — Monitoring Statistics (확인일: 2026-07-02)
- PostgreSQL Docs — Backup and Restore (확인일: 2026-07-02)
- Microsoft Learn — Elastic Clusters - Azure Database for PostgreSQL (확인일: 2026-07-02)
이 글은 Supabase Multigres 발표, PostgreSQL 공식 문서, Microsoft Azure Database for PostgreSQL Elastic Clusters 문서를 기준으로 정리한 일반적인 IT 운영 가이드다.
실제 기능, 가격, 지원 범위, SLA, 보안 요구사항은 서비스와 버전에 따라 바뀔 수 있으므로 production 변경 전 공식 문서와 조직 DBA·보안 기준을 다시 확인해야 한다.
댓글
댓글 쓰기