본문으로 건너뛰기

3.2 PostgreSQL 분기 제품

운영 규모의 데이터를 준비하려고 branch 생성 API를 비교합니다. 비슷한 이름이지만 실제 작업은 서로 다릅니다. 어떤 경로는 기존 데이터를 공유합니다. 어떤 경로는 backup을 복원한 뒤 WAL을 재생합니다. 같은 제품에서도 요금제나 스토리지 구성에 따라 경로가 달라집니다. 비교 단위를 제품 하나로 고정하면 생성 시간과 저장 비용의 조건부터 누락됩니다.

이 장의 비교 기준일은 2026-09-30입니다. Neon, Xata Cloud와 OSS를 구분합니다. Tiger Cloud의 두 fork 경로, Aurora clone, DBLab thin clone도 구분합니다. 표에는 문서로 확인한 동작을 적고, 미확인인 부분은 그대로 남깁니다. 공급사 안내 시간의 해석 범위는 각 문서의 조건으로 한정합니다. 이를 전체 제품의 성능 순위로 해석하지 않습니다. 이 장에서는 동일 조건의 자체 측정을 수행하지 않았습니다.

생성 모드와 공유 계층​

제품과 모드데이터 준비 방식공유 계층시점의 기준운영 형태
Neon 데이터 포함 branch저장 이력 참조page 버전과 timeline부모의 분기 시점관리형 서비스
Xata CloudXatastor CoWZFS zvol 기반 블록스토리지 분기점관리형 서비스
Xata OSS구성별 branch 생성OpenEBS 로컬 또는 Mayastor, 실제 CoW는 조건부구성별, 미확인자체 운영
Tiger Cloud Free forkFluid Storage CoW블록과 chunk최신, 최근 snapshot, 보존 범위 내 시점관리형 서비스
Tiger Cloud Paid forkbackup restore와 WAL replay이 경로의 데이터 공유 미확인복원 목표 시점관리형 서비스
Aurora CoW clone변경되지 않은 page 공유Aurora 스토리지clone 생성 기준 상태관리형 서비스
DBLab thin clone수집 사본의 snapshot에서 생성ZFS 또는 LVM보존 snapshot과 branch 포인터자체 운영 가능

아래 지도는 생성 방식을 구분하는 분류도입니다. 가로축은 파일시스템과 블록에서 DB page 버전으로 이동하는 구현 계층입니다. 세로축은 복원 작업과 기존 데이터 참조를 구분합니다. 좌표 간 거리는 측정값이 아니며, 높고 오른쪽일수록 좋다는 의미도 없습니다. 실제 참조 공유를 확인한 모드에만 좌표를 부여합니다.

Tiger의 backup 복원 경로는 세로축의 복원 쪽에 해당합니다. 다만 공유 계층을 지정할 근거가 없어 점 표시는 생략했습니다. Xata OSS도 StorageClass별 실제 복사 경로가 미확인입니다. 따라서 표에서 조건부로 비교합니다. 도식에 점이 없다는 이유로 기능 미지원으로 해석하지 않습니다. 시점 선택은 별도의 속성입니다. 같은 참조 공유 방식에서도 요청 시점에 따라 준비 작업이 달라집니다. 최근 snapshot을 고르는 요청과 더 최신 상태를 요구하는 요청을 구분합니다.

Neon의 데이터 범위와 서비스 경계​

Neon의 데이터 포함 branch에는 database, role, extension이 포함됩니다. schema와 data도 포함됩니다. 다만 extension 포함이 지원 목록 밖의 바이너리 복제까지 뜻하지는 않습니다. 데이터베이스 내부 객체의 범위와 서비스가 실행하는 소프트웨어의 지원 범위를 따로 확인해야 합니다. 이 구분을 유지해야 특정 extension이 필요한 시험 환경을 준비할 수 있는지 판단할 수 있습니다.

저장 구조에서는 자식 timeline에 필요한 page 버전이 없으면 조상 timeline을 조회합니다. 이 조상 참조 때문에 전체 데이터를 처음부터 복사하는 방식과 차이가 납니다. page 재구성과 layer 파일 관리는 별도 문서에 정리했습니다. Neon 아키텍처 및 Timeline과 Branch 내부를 참고합니다. 여기서는 공유 계층만 비교합니다.

서비스 경계는 2026년의 기능 확대도 반영해야 합니다. 9월 backend GA 설명에서는 Auth 상태도 branch를 따라 분기합니다. object storage의 bucket 및 object도 분기합니다. 이 설명의 범위는 Neon backend 객체로 한정합니다. 외부 인증 서비스나 외부 S3 bucket의 복제까지 뜻하지는 않습니다. Functions의 scheduled trigger는 자식 branch에 상속됩니다. 다만 비활성 상태로 시작합니다. 이 동작을 모든 pg_cron job에 적용할 근거는 없습니다.

DBA의 검토 기록에는 DB 내부 객체, Neon backend 객체, 외부 연동을 나누어 적도록 제안합니다. Functions에는 branch 연결 정보가 주입됩니다. 이 사실만으로 모든 사용자 secret과 replication 설정의 안전한 분리를 판단하기는 어렵습니다. 사실 대장에서 이 전체 규칙은 미확인입니다. 환경 생성 후에는 시험에 필요한 객체가 있는지 확인하도록 검증 범위를 정합니다. 외부 연결 대상도 각각 확인합니다.

공개 저장 엔진을 직접 운영하는 문제도 별도입니다. 공식 docker-compose README는 해당 구성을 이미지 테스트용으로 설명합니다. 사용 가능한 서비스 배포를 목적으로 하지 않는다고 명시합니다. 저장소 공개 사실만으로 관리형 Neon과 같은 기능을 자체 호스팅한다고 보기는 어렵습니다. 인증, 과금, 수명 관리 기능이 이에 해당합니다. 관리형 서비스 후보를 자체 운영 후보로 바꾸려면 운영 구성의 근거가 추가로 필요합니다.

Xata Cloud와 OSS의 저장 경로​

Xatastor의 공식 구조는 PostgreSQL에서 compute 측 XFS로 이어집니다. 그다음 Rust 기반 NVMe-oF, storage 측 ZFS zvol 순서입니다. 네트워크 블록 장치로 제공된다는 사실과 ZFS 기반 공유를 함께 적어야 합니다. 이를 ZFS와 무관한 별도 CoW 계층으로 설명하면 실제 저장 경로를 누락합니다. 반대로 compute의 PostgreSQL 데이터 디렉터리가 직접 ZFS dataset 위에 있다는 설명도 이 구조와 맞지 않습니다.

Xata OSS는 CloudNativePG와 OpenEBS를 사용합니다. 로컬 스토리지 또는 Mayastor 경로를 제공합니다. 상용 Xatastor는 공개 범위에서 제외됩니다. 따라서 Cloud의 생성 시간이나 저장 효율을 OSS 설치의 예상값으로 그대로 사용하지 않습니다. 각 로컬 StorageClass에서 CoW와 전체 복사 중 무엇이 실행되는지도 확인해야 합니다. 이 부분은 사실 대장에서 미확인으로 남아 있습니다.

자체 운영 검증에서는 코드 버전과 StorageClass를 먼저 고정하도록 제안합니다. 그다음 CSI snapshot과 PVC clone 지원을 확인합니다. branch 생성 시 실제 경로와 fallback 발생 여부도 확인합니다. 여기서 fallback은 조사 항목이며 이미 재현한 장애 사례가 아닙니다. 데이터 크기를 바꾼 시간 측정만으로 원인을 확정하기는 어렵습니다. 생성 리소스와 스토리지 동작을 함께 기록해야 합니다.

공개 핵심 구성 요소의 라이선스는 Apache 2.0입니다. OSS에는 적대적 멀티테넌시 보호가 빠져 있습니다. 공급사는 이 OSS를 공개 PaaS에 사용하는 것을 권장하지 않습니다. 이 권고의 의미는 공급사가 설명하는 운영 보안 범위로 한정합니다. 외부 고객 제공에 BYOC 구매가 법적으로 필수라는 주장은 별개입니다. 라이선스의 허용 범위와 운영 보안 범위는 서로 다른 판단 항목입니다.

설치 구성과 도구의 흐름은 Xata OSS와 Kubernetes를 참고합니다. 도입 범위에는 스토리지 외에도 gateway, control plane 검토가 포함됩니다. 인증과 운영 도구도 검토합니다. 기존 CloudNativePG 운영 경험만으로 도입 범위를 branch operator 하나의 추가로 한정하기는 어렵습니다. role, secret, scheduled job과 replication 설정의 복제 정책도 개별 확인 대상으로 남깁니다.

Tiger의 두 fork 경로와 Aurora clone​

Tiger Cloud의 현행 fork 문서는 Free와 Paid의 경로를 구분합니다. Free는 CoW, Paid는 backup restore 및 WAL replay 경로입니다. 공급사 문서에서는 전자를 약 3090초로 안내합니다. 후자는 통상 520분 이상으로 안내합니다. 이 수치는 보장 시간도, 이 장에서 측정한 결과도 아닙니다. 도입 시에는 대상 서비스에 적용되는 모드를 다시 확인해야 합니다. 동일 데이터의 SQL 접속 준비 시간도 측정해야 합니다.

Fluid Storage 설명에는 --now, --last-snapshot, --to-timestamp가 등장합니다. 각각 최신 시점, 최근 snapshot, 보존 범위 내 지정 시점을 선택합니다. 선택한 시점에 따라 최신성과 WAL 재생량이 달라집니다. 따라서 모든 fork 요청을 같은 시간으로 비교하지 않습니다. 운영 장애 직전 상태가 필요한 시험과 최신 데이터가 필요한 시험은 요청 조건부터 나누어 기록합니다.

과금도 경로별로 다릅니다. CoW 고성능 스토리지는 달라진 chunk를 기준으로 설명합니다. 전통적 경로는 전체 서비스 스토리지를 과금합니다. tiered data의 공유 규칙은 별도로 다룹니다. fork에는 data, schema, configuration이 포함됩니다. 새 비밀번호를 사용하는 tsdbadmin도 포함됩니다. 다만 모든 custom role과 외부 secret, job의 규칙은 미확인입니다. 관리자 비밀번호가 그대로 복제된다고 기술하지 않습니다.

Aurora CoW clone은 별도 volume의 논리적 상태를 제공합니다. 동시에 변경되지 않은 page를 공유합니다. 원본과 clone 어느 쪽에서 쓰기가 발생해도 새로운 page 공간이 필요할 수 있습니다. 그러므로 자식에서 읽기만 수행한다는 조건으로 추가 저장량을 0으로 예산화하지 않습니다. 부모 대량 변경과 자식 변경을 따로 실행하는 시험이 필요합니다.

Aurora에는 clone 개수와 리전 등의 제약이 있습니다. 현행 문서는 최대 15개의 CoW clone 이후 full-copy 동작을 설명합니다. 비교할 때는 이러한 생성 제약을 반영합니다. DB instance의 준비도 저장소 공유와 별도 작업입니다. PostgreSQL 호환이라는 이유로 Aurora를 일반 PostgreSQL의 파일시스템 clone과 동일하게 분류해서는 안 됩니다. 엔진과 외부 설정의 복제 범위는 Aurora PostgreSQL의 조건으로 검토합니다.

DBLab의 기준 사본과 운영 책임​

DBLab은 수집한 기준 사본에서 ZFS 또는 LVM 기반 thin clone을 제공합니다. 제품 비교에서는 원본에서 데이터를 수집하는 작업을 구분합니다. 이미 준비된 사본에서 clone을 만드는 작업도 따로 구분합니다. clone 생성 시간만으로 전체 환경 준비 비용을 설명하면 최초 수집과 갱신 비용이 빠집니다. 그러면 기존 운영 DB를 유지하는 구성의 부담을 놓치게 됩니다.

4.0에서 도입한 명명된 branch는 snapshot을 가리킵니다. 접속 가능한 PostgreSQL clone과는 구별됩니다. 사용자 요청의 commit으로 상태를 보존하는 기능도 있습니다. DBLab은 그 이전부터 자동 snapshot을 생성했습니다. 따라서 사용자가 commit한 시점만 남긴다고 설명하지 않습니다. 4.2의 clone 업그레이드는 pg_upgrade --link를 사용합니다. 파일 소유권 처리 같은 작업도 준비 시간에 영향을 줍니다.

clone 생성 시에는 접속 자격증명을 지정합니다. 원본 PostgreSQL major version에 맞는 이미지도 선택합니다. extension 바이너리와 수집 방식의 호환 조건도 검토합니다. physical 수집은 해당 시점의 page 상태와 통계를 보존하는 데 유리합니다. 그렇더라도 실행 계획과 시간의 동일성을 보장하지 않습니다. 설정, 버전, hardware와 부하를 맞춘 검증이 뒤따라야 합니다.

명령과 설치 흐름은 DBLab Engine에 연결합니다. 이 장에서는 자체 운영의 책임을 나누어 평가하도록 제안합니다. 평가 항목은 기준 데이터 갱신, clone 접속, 보존과 정리입니다. 관리형 제품도 애플리케이션의 외부 연결과 데이터 접근 정책까지 자동으로 해결한다고 가정하지 않습니다. 후보를 선정한 뒤에는 생성 성공, SQL 준비, 첫 쿼리를 각각 기록합니다. 삭제 후 공간 회수도 기록해 다음 Part의 선택 조건에 대입합니다.

참고​