5.5 온프레미스 선택 매트릭스
네 가지 접근을 살펴봤으니 이제 선택할 차례입니다. 먼저 순수 사실을 표로 정리하고, 판단은 뒤의 산문에서 다룹니다.
비교표
| 항목 | Neon 자체 호스팅 | ZFS 수동 | DBLab Engine | Xata OSS | Dolt/Doltgres |
|---|---|---|---|---|---|
| CoW 계층 | 저장 엔진(page version) | 파일시스템(블록) | 파일시스템(ZFS/LVM 블록) | 네트워크 블록 장치 | 저장 구조(Prolly tree) |
| 요구 인프라 | Docker 또는 Rust 빌드, S3 호환 저장소 | Linux, ZFS | Linux, ZFS 또는 LVM, Docker | Kubernetes, CNPG, OpenEBS | 단일 바이너리 또는 Docker |
| PostgreSQL 바이너리 | Neon 패치 버전 | vanilla | vanilla | vanilla | 별도 엔진(Postgres 호환) |
| 확장 지원 | Neon 빌드에 포함된 것 | 제한 없음 | 제한 없음 | 플랫폼이 제공하는 이미지 범위 | Go로 재구현한 목록만 |
| 분기 시점 | 임의 LSN (history window 안) | snapshot 시점 | snapshot(commit) 시점 | 볼륨 snapshot 시점 | commit 시점 |
| branch 간 머지 | 없음 | 없음 | 없음 | 없음 | 있음 (3-way, 충돌 해결) |
| branch당 compute | 별도 compute(scale-to-zero 가능) | 별도 PostgreSQL 프로세스 | 별도 컨테이너 | 별도 CNPG cluster(scale-to-zero plugin) | 같은 프로세스 |
| 라이선스 | Apache 2.0 (control plane 비공개) | CDDL(OpenZFS) | Apache 2.0 (SE/EE 상용) | Apache 2.0 (Xatastor 비공개) | Apache 2.0 |
| upstream이 밝힌 용도 | compose는 테스트용, cargo neon은 개발용 | 범용 | 운영 사용 전제 | 다중 팀 플랫폼, 단일 인스턴스에는 과함 | 1.0 GA(2026-08), 호환성 제약 존재 |
| 이 노트 실측 | Part III | 없음 | 없음 | 없음 | 5.3 |
판단
이미 ZFS 위에서 PostgreSQL을 운영하는 DBA 팀
가장 간단한 선택은 DBLab Engine입니다. 원본 운영 방식을 바꾸지 않고 옆에 서버 한 대를 추가합니다. physical 모드에서는 bloat와 통계까지 운영 환경과 같은 clone을 받습니다. ZFS 수동 절차(5.1)는 원리를 이해하고 장애 시 직접 복구하려면 알아 둬야 합니다. 다만 일상 도구로는 DBLab의 보존 정책과 CLI가 더 낫습니다. 단발성 검증이 한두 번이라면 5.1 절차만으로 충분합니다.
Kubernetes와 CloudNativePG를 표준으로 정한 팀
Xata OSS가 유일한 후보입니다. 다른 접근은 VM을 전제로 하거나(ZFS, DBLab), Kubernetes 운영 사례가 적습니다(Neon 자체 호스팅). 다만 Mayastor 스토리지도 운영에 도입해야 합니다. 따라서 스토리지 팀과 합의하지 않고 DBA 팀만 결정하기는 어렵습니다. 파일럿은 kind에서 진행하고, 성능은 Linux 노드의 Mayastor에서 따로 검증합니다.
데이터 변경 자체를 리뷰하고 합쳐야 하는 경우
Dolt/Doltgres 외에는 대안이 없습니다. 참조 데이터, 설정 테이블, agent 실험 결과처럼 "누가 무엇을 바꿨고 이것을 받아들일지"가 질문이라면 branch만으로는 부족합니다. diff와 머지가 필요합니다. 1.0 이후 upstream은 production 사용을 표방합니다. 하지만 기존 OLTP를 검증 없이 옮기는 것은 지연과 확장 목록 제약 때문에 권하지 않습니다. 참조 데이터만 Doltgres로 분리하는 설계가 현실적입니다.
Neon의 내부를 이해하는 것이 목적인 경우
Part III의 docker-compose와 cargo neon이 적합합니다. 다만 그 결과를 사내 서비스의 기반으로 확장하려면 control plane, 인증, compute 스케줄링을 직접 만들어야 합니다. 이 부분이 Neon이 회사로서 구축한 영역입니다. Neon의 저장 엔진을 사용하겠다는 결정은 "Rust 코드베이스를 유지보수하겠다"는 결정과 같습니다.
짧은 실험 하나만 필요한 경우
pg_basebackup 한 번이 CoW 도구를 구축하는 것보다 빠릅니다. 컨테이너로 운영 중이라면 docker commit은 답이 아닙니다. 공식 PostgreSQL 이미지처럼 PGDATA가 volume에 있으면 Docker는 volume 내용을 이미지에 담지 않습니다. 따라서 데이터가 누락된 사본이 만들어집니다. 볼륨 스냅샷 기능을 사용하는 방식이 맞습니다. reflink를 지원하는 파일시스템에서는 cp --reflink=always로 볼륨 디렉터리를 복사해도 됩니다. 또는 정지 후 디렉터리를 그대로 복사합니다.
thin clone 도구는 사본을 반복해서 만들 때 가치가 생깁니다. 한 번 만들고 끝나는 사본에는 어떤 도구도 과합니다.
관리형 서비스 제공자 관점의 일반론
관리형 PostgreSQL 서비스에 branching을 추가하려는 제공자에게는 질문이 하나 남습니다. "CoW를 어느 계층에 두는가"입니다. 이 Part의 다섯 접근이 그 선택지를 그대로 보여 줍니다.
저장 엔진 계층(Neon 방식)은 임의 LSN 분기와 scale-to-zero를 지원합니다. 다만 PostgreSQL을 포크해야 하고 확장 호환성은 제공자가 책임져야 합니다. 블록 스토리지 계층(Xata, Aurora 방식)은 vanilla PostgreSQL을 유지하면서 즉시 분기를 제공합니다. 대신 스토리지 시스템을 직접 만들거나 운영해야 합니다. 파일시스템 계층(ZFS, DBLab 방식)은 구현 비용이 가장 낮고 검증된 기술입니다. 하지만 노드 단위 제약이 있습니다. 다중 노드 서비스로 확장하려면 스토리지 계층을 다시 설계해야 합니다.
어느 계층이든 공통으로 결정할 항목은 같습니다. history 보존 기간을 정해야 합니다. 이때 저장 비용과 분기 가능 시점을 함께 고려합니다. branch당 compute의 배정 방식과 회수 시점도 정해야 합니다. 부모를 삭제할 때 자식의 블록 소유권을 누가 갖는지도 결정해야 합니다. Aurora가 clone 간 재분배 규칙을 문서화한 이유입니다. 민감 데이터가 branch로 복제되는 방식도 통제해야 합니다. 이 항목들은 6.5 관리형 PostgreSQL 관점의 시사점에서 Neon의 답과 함께 다시 살펴봅니다.
결정 절차
이 순서는 "PostgreSQL을 바꾸지 않는 선택을 먼저 고른다"는 원칙을 따릅니다. Neon 자체 호스팅은 학습 경로로만 남겨 두었습니다. 이를 서비스 기반으로 삼는 판단은 별도의 플랫폼 투자 결정입니다.
비용은 어디에서 드는가
다섯 접근은 "저장 공간은 변경분만 든다"는 점에서 같습니다. 차이는 branch당 compute와 운영 인력에서 발생합니다.
| 항목 | Neon 자체 호스팅 | ZFS 수동 | DBLab | Xata OSS | Dolt/Doltgres |
|---|---|---|---|---|---|
| branch 추가 저장 공간 | 변경 page version | 변경 블록 | 변경 블록 | 변경 블록 | 변경 chunk |
| branch당 compute | compute 프로세스 1 (수동 종료 또는 자체 스케줄러 구현 시 0) | PostgreSQL 1 | 컨테이너 1 | CNPG cluster 1 (scale-to-zero plugin 사용 시 0) | 없음 |
| 상시 구성 요소 | pageserver, safekeeper(docker-compose 예제 기준 3, 가용성 요구에 따라 구성), broker, S3 | 없음 | dblab-server 1 | control plane, Keycloak, operator, 스토리지 | 서버 1 |
| 운영 지식 | Rust 서비스, S3, LSN 모델 | ZFS | ZFS, Docker | Kubernetes, CNPG, Mayastor | Dolt 버전 관리 모델 |
ZFS와 DBLab은 branch를 만들 때마다 PostgreSQL 프로세스가 하나씩 늘어납니다. 이 때문에 메모리가 병목이 됩니다. 20개 branch가 동시에 실행되면 shared_buffers 20개가 필요합니다. Neon과 Xata는 유휴 branch의 compute를 내려 이 문제를 피합니다. 대신 상시 구성 요소가 많습니다. 자체 호스팅에서는 이 자동 정지 기능이 기본으로 제공되지 않습니다. Xata OSS에서는 scale-to-zero plugin이 그 역할을 합니다. Neon 자체 호스팅에는 관리형 서비스의 suspend와 resume 스케줄러가 없습니다. 따라서 compute를 언제 내리고 올릴지 직접 구현해야 합니다. 어느 쪽이 저렴한지는 "동시에 살아 있는 branch 수"와 "branch가 유휴인 시간 비율"로 결정됩니다. 도구를 선택하기 전에 팀의 사용 패턴에서 이 두 값을 먼저 측정해야 합니다.
각 접근에서 흔한 실패
- ZFS 수동: clone의
archive_command를 끄지 않아 운영 백업 저장소에 다른 timeline WAL이 섞임. 5.1의 「놓치기 쉬운 조건」 참고. - DBLab: 골든 사본 갱신이 멈춘 사실을 모르고 오래된 데이터로 마이그레이션을 검증함. 갱신 지연 알람이 필요.
- Xata OSS: kind에서 검증한 뒤 운영 스토리지 클래스가 CoW clone을 지원하지 않아 branch 생성이 전체 복사로 동작함.
- Dolt/Doltgres: 운영 OLTP를 통째로 옮긴 뒤 지연과 확장 목록 제약이 발생함. 참조 데이터만 분리하는 설계가 필요.
- Neon 자체 호스팅: compose 구성에 storage controller와 인증이 없다는 사실을 뒤늦게 확인함. 서비스 기반으로 확장하는 과정에서 control plane을 처음부터 만들게 됨.
도입 전에 답해야 하는 질문
- branch를 만드는 주체는 누구인가. DBA만인가, 개발자 전원인가, CI 파이프라인인가. 주체가 늘어날수록 self-service API와 보존 정책이 필수가 됩니다.
- 원본 데이터를 그대로 복제해도 되는가. 개인정보가 있다면 logical 모드(DBLab), schema-only 후 마스킹 적재, pgstream 마스킹 스트림 중 하나를 설계에 포함해야 합니다.
- branch의 수명은 얼마인가. 몇 시간이라면 어떤 접근이든 가능합니다. 하지만 몇 주 동안 유지하면 원본 변경량만큼 snapshot이 커지는 문제가 모든 CoW 계층에서 똑같이 발생합니다.
- 되돌리기(reset)와 과거 시점 분기가 필요한가. 여기서는 두 가지를 구분합니다. "즉시 과거 분기"는 보존된 history 안에서 시점을 선택합니다. 복사 없이 바로 사본을 얻는 방식입니다. Neon의 임의 LSN 분기와 DBLab physical 모드의 보존 snapshot이 여기에 해당합니다. "복원 시간이 드는 PITR"은 백업과 WAL을 재생해 시점을 맞추는 방식입니다. Xata의 PITR backup과 표준 PostgreSQL의 base backup 더하기 WAL archive 절차가 여기에 해당합니다. 사고 재현처럼 반복 시도가 필요하면 앞쪽이 적합합니다. 규제 대응처럼 한 번의 정확한 복구가 목표라면 뒤쪽이 적합합니다.
연습 문제
- 팀의 지난 한 달 사본 요청 건수, 동시 사용 수, 평균 수명을 조사해 위 비용 표에 대입합니다.
- 개인정보 컬럼이 있는 스키마에서 각 접근별로 마스킹이 들어갈 지점을 그립니다.
- 결정 절차의 첫 질문에 "예"라고 답할 테이블이 조직에 있는지 찾아봅니다.
다음 단계
Part VI는 Neon을 실제로 사용하거나 비교 대상으로 삼을 때 필요한 비용, 성능, 내구성, 호환성을 정리합니다. 온프레미스 대안과 비교할 기준이 필요하면 이 장의 표를 옆에 두고 읽습니다.