ClickHouse Managed Postgres GA: 복제 지연·백업 과금·브랜칭 범위 점검
11월 9일 정식 제공된 Managed Postgres의 운영 경계를 살펴본다. ClickPipes 기본 60초 간격, 공유 트랜잭션의 부재, 백업 포함량과 전송 과금, PITR 브랜치와 Xata 통합 계획을 구분한다.
트랜잭션 데이터베이스와 분석 데이터베이스 사이의 비동기 복제와 시차를 표현한 생성형 개념 이미지. 실제 제품 화면이나 성능 측정 결과는 아니다.
2026년 11월 9일 ClickHouse가 Managed Postgres의 정식 제공(GA)을 발표했다. 트랜잭션은 PostgreSQL에서 처리하고 분석은 ClickHouse로 넘기려는 팀이 살펴볼 만한 변화다. 현재 GA 범위는 AWS이며 GCP는 Private Preview다. 같은 발표에 포함된 Xata 인수는 앞으로의 개발·에이전트용 데이터베이스 환경을 확장하기 위한 계획이다. 공식 GA 발표
도입 검토에서 먼저 확인할 것은 분석 데이터의 지연 허용치, GA 전환 후 비용, 현재 제공되는 브랜치의 생성 방식이다. 이 세 가지를 정하지 않으면 연결은 성공했는데 주문 화면이 뒤늦게 갱신되거나, 테스트 환경 비용이 예상보다 커질 수 있다.
지금 사용할 수 있는 범위부터 나눈다
공식 문서를 기준으로 기능 상태를 정리하면 다음과 같다.
| 항목 | 확인된 상태 | 도입 시 확인할 점 |
| Managed Postgres | AWS에서 GA, GCP는 Private Preview | 대상 리전과 필요한 인스턴스 구성 |
| ClickPipes 연동 | 초기 적재와 지속적인 CDC 지원 | 동기화 간격과 대상 테이블 |
| WalShadow | Managed Postgres에서 Private Preview | 별도 접근 가능 여부와 운영 조건 |
| 기존 브랜치 | PITR로 복원한 독립 PostgreSQL 배포 | 복원 시간과 별도 인프라 비용 |
| Xata 기반 확장 | 향후 통합 계획 | 즉시 브랜치·자동 유휴·scale-to-zero 제공 시점 |
GA 발표의 성능 수치는 공급자의 특정 환경에서 나온 결과다. 실제 애플리케이션이 I/O, CPU, 잠금 경합, 연결 수 중 어디에 묶이는지에 따라 효과가 달라진다. 이전을 검토한다면 현재 쿼리 지연과 부하 패턴부터 기록하는 편이 낫다.
1. 결제 완료 화면은 어느 데이터베이스를 읽는가
Managed Postgres와 ClickHouse 사이의 복제는 비동기다. PostgreSQL에서 커밋한 변경이 분석 쪽에 보이기까지 시간이 걸릴 수 있다. 공식 문서는 CDC와 pg_clickhouse가 두 데이터베이스에 걸친 공유 트랜잭션을 제공하지 않는다고 명시한다. pg_clickhouse로 PostgreSQL 인터페이스에서 분석 테이블을 조회할 수 있어도 이 경계는 유지된다. 트랜잭션과 복제 경계
이를 애플리케이션의 읽기 경로에 반영해야 한다.
- 주문 생성 직후의 확인 화면, 재고 차감 결과, 계정 권한 확인처럼 최신 커밋이 필요한 요청은 해당 쓰기를 확인할 수 있는 PostgreSQL 기본 인스턴스(primary)를 기준으로 처리한다.
- 시간대별 매출, 이용 추세, 대규모 집계는 허용 지연을 정하고 ClickHouse에서 읽는다.
- 한 화면에 두 종류의 데이터를 함께 보여 준다면 분석 영역의 갱신 시점을 표시한다.
- 분석 결과가 아직 없다는 이유로 이미 성공한 쓰기를 다시 시도하지 않도록 한다.
예를 들어 주문 API는 PostgreSQL 커밋 후 주문 번호를 돌려준다. 확인 화면은 그 주문 번호로 PostgreSQL primary를 조회하고, 매출 대시보드는 분석 데이터가 도착한 뒤 집계에 반영한다. 이처럼 쓰기 성공 여부와 분석 반영 여부를 분리하면 사용자가 중복 주문을 만드는 상황을 줄일 수 있다.
PostgreSQL 안에서도 조회 대상을 확인한다. Managed Postgres의 기본 읽기 복제본은 객체 저장소의 WAL을 가져와 재생하는 방식이라, 쓰기량이 적으면 지연이 60초에 가까워질 수 있다고 안내한다. 이는 아래에서 설명하는 ClickPipes의 동기화 간격과 별개의 경로다. 최신 결과가 필요한 API를 읽기 복제본으로 보내지 않도록 연결 주소도 점검한다. 읽기 복제본의 지연 특성
2. 기본 ClickPipes 설정에서 60초를 확인한다
Managed Postgres의 내장 ClickPipes 연동 문서에는 동기화 간격 기본값이 60초로 안내되어 있다. 이 값은 변경을 가져오는 간격이며, 모든 변경이 정확히 60초 안에 보인다는 지연 보장은 아니다. 초기 적재량과 처리 상황도 따로 확인해야 한다. WalShadow의 낮은 지연 설명을 기존 ClickPipes 설정에 그대로 적용해서는 안 된다. ClickPipes 설정 문서
설정 화면에서는 다음 항목을 함께 검토한다.
- 기존 데이터와 이후 변경이 모두 필요하면
Initial load + CDC를 선택할 계획인지 확인한다.Initial load only는 지속 동기화를 하지 않고,CDC only는 기존 스냅샷을 건너뛴다.
Preserve NULL values from source를 결정한다. 문서상 이 설정은 파이프 생성 후 바꿀 수 없으므로 NULL과 기본값을 구분하는 업무 로직을 먼저 살펴야 한다.
- 같은 테이블 이름을 가진 스키마가 여러 개라면 대상 이름의 충돌을 점검한다.
- IP 접근을 제한했다면 해당 리전의 ClickPipes 연결이 허용되는지 확인한다.
설정을 마친 뒤에는 단순한 “연결됨” 대신 커밋부터 분석 조회에 보이기까지의 시간을 측정한다. 평상시 지연뿐 아니라 배치 쓰기, 스키마 변경, 연결 복구 뒤의 지연도 확인할 항목이다. 허용 기준은 서비스 요구사항에 맞춰 팀이 정해야 한다.
3. GA 이후 백업과 전송 비용을 다시 계산한다
GA 발표는 베타 할인이 종료되고 백업 저장 공간과 공용 네트워크 송신이 과금 대상이 된다고 안내한다. 구체적인 포함량은 요금 문서에서 확인해야 한다. GA 비용 변경 안내
AWS 요금 문서는 2026년 11월 9일부터 다음 기준을 설명한다.
- 인스턴스는 CPU·메모리·로컬 NVMe 저장 공간을 포함한 VM 구성으로 가격이 정해진다.
- 프로비저닝한 디스크 크기만큼의 백업 저장 공간은 포함되며 초과분은 리전별 저장 요금이 적용된다.
- 데이터 전송에는 ClickHouse Cloud 전송 요율이 적용된다.
- Managed Postgres에서 ClickHouse로 복제하는 ClickPipes와 WalShadow 자체는 무료다.
- 확장·유지보수 중 이전 인스턴스와 새 인스턴스가 잠시 겹쳐 실행되면 중복 과금 구간이 생길 수 있다.
견적에는 운영 인스턴스와 HA 구성, 읽기 복제본, 백업 초과분, 전송량, 테스트 브랜치 유지 시간을 각각 적는다. 대상 ClickHouse 서비스 사용료도 별도 예산 항목으로 확인한다. 복제 기능의 무료 범위를 전체 데이터 플랫폼 비용으로 넓혀 잡지 않는 것이 핵심이다.
기존 베타 사용자는 지난달 청구서만으로 다음 달 비용을 예상하기보다 현재 구성으로 계산기를 다시 돌려 보는 것이 좋다. 리전과 실제 보관량에 따라 달라지므로 단일 최저 가격을 전체 운영 비용처럼 사용하지 않는다.
4. 현재 PITR 브랜치와 Xata 계획을 구분한다
현재 Managed Postgres 브랜치는 백업을 복원하고 필요한 WAL을 재생해 만드는 독립 PostgreSQL 배포다. 데이터 크기와 재생할 WAL 등에 따라 생성에 수분에서 수십 분이 걸릴 수 있다. 공식 문서는 일상 개발에는 로컬 환경과 합성·정제 데이터를, 운영과 유사한 검증에는 브랜치를 활용하는 방식을 권장한다. 브랜칭 동작과 권장 용도
Xata 인수 발표가 설명하는 copy-on-write 기반 즉시 브랜칭, 자동 유휴, scale-to-zero의 Managed Postgres 통합은 앞으로 진행될 계획이다. 기존 PITR 브랜치를 매 PR마다 즉시 만들어 쓰는 비용 모델로 가정하면 준비 시간과 유지 비용을 놓칠 수 있다. 향후 통합 범위
CI에 브랜치를 붙이기 전에는 생성 완료를 기다리는 단계, 최대 수명, 종료 담당, 테스트 데이터 정제 여부를 먼저 정한다. 운영 데이터에서 복원한 브랜치에는 원본의 민감한 내용이 남을 수 있으므로 개발자나 에이전트에게 제공할 데이터 범위도 검토해야 한다.
작은 검증부터 시작하는 도입 체크리스트
다음은 실제 환경에 적용하기 전에 준비할 검증 제안이다.
| 검증 | 남길 결과 |
| 새 행 삽입 후 즉시 조회 | PostgreSQL 읽기 결과와 ClickHouse 반영 시각 |
| 같은 키의 수정·삭제 | 대상 쿼리가 반환하는 최종 상태와 삭제 반영 결과 |
| NULL·타임스탬프·소수 값 | 변환 전후 의미가 유지되는지 확인한 표본 |
| 초기 적재 완료 후 대조 | 행 수와 주요 키·업무 집계의 일치 여부 |
| 중단 후 복구 | 누락·중복 확인 결과와 따라잡는 데 걸린 시간 |
| 임시 브랜치 생성 | 준비 시간, 접근 범위, 유지 비용과 종료 절차 |
행 수 비교는 빠른 출발점이다. 공식 마이그레이션 문서도 원본과 대상의 테이블별 행 수 대조를 제시한다. 다만 개수가 같아도 값이 다를 수 있으므로 중요한 키와 업무 합계까지 검토하고, 계속 쓰기가 발생하는 환경에서는 비교 시점도 맞춘다. 마이그레이션 데이터 검증
이번 GA를 검토하는 팀은 어떤 읽기가 최신 커밋을 요구하는지, 분석이 얼마나 늦어도 되는지, 복제·백업·브랜치에 얼마를 배정할지부터 결정하면 된다. 그 기준이 잡히면 작은 비민감 데이터셋으로 시작해 운영 확장 여부를 판단하기가 쉬워진다.
확인 기준은 2026년 11월 10일의 공식 발표와 공개 문서다. 실제 계정에서 서비스 생성, 유료 부하 테스트, 마이그레이션이나 인증정보 생성은 수행하지 않았다. 문서의 기본값과 기능 제공 상태는 적용 전에 다시 확인해야 한다.