Part V. 온프레미스 대안: Thin Clone 직접 구성
Neon의 branching을 사내 서버에서 그대로 재현하고 싶다는 요구는 자연스럽습니다. 하지만 2026년 시점에는 Neon 자체 호스팅을 첫 선택으로 삼기 어렵습니다. 저장소 엔진(pageserver, safekeeper, compute)은 Apache 2.0으로 공개되어 있습니다. 그러나 branch 생성, compute 기동, 인증, 과금을 통합하는 control plane은 비공개입니다. 저장소의 docker-compose/도 README에 적힌 대로 이미지 테스트용입니다. Part III에서 이 구성으로 branch를 만들어 보았지만, 학습을 위한 실습일 뿐 운영 환경 설계는 아닙니다.
그래서 이 Part에서는 질문을 바꿉니다. "Neon을 어떻게 설치하나"가 아니라 "copy-on-write로 데이터베이스 사본을 순식간에 만드는 기능을 온프레미스의 어느 계층에 두어야 하나"입니다. 파일시스템 계층(ZFS)부터 살펴봅니다. 이어 그 위에 branching 워크플로우를 추가한 도구(DBLab Engine), 저장 구조 자체가 버전 관리인 엔진(Dolt/Doltgres), Kubernetes 블록 스토리지 계층(Xata OSS)을 차례로 다룹니다. 각 접근 방식에 필요한 인프라와 운영 부담도 비교합니다.
Neon의 page-version 단위 CoW가 어떤 계보에 속하는지는 1.2 Copy-on-Write와 Thin Clone 계보에서 먼저 읽어 두면 이 Part의 비교를 더 쉽게 이해할 수 있습니다.
이 Part의 실습 범위
| 장 | 실습 방식 | 이 노트에서 실측 여부 |
|---|---|---|
| 5.1 ZFS | Linux 서버 명령 절차 | 미실측 (macOS에 ZFS 커널 모듈 없음) |
| 5.2 DBLab Engine | 공식 CLI 명령 정리 | 미실측 (Linux + ZFS 필요) |
| 5.3 Dolt/Doltgres | Docker 컨테이너 1개 | 실측 (Doltgres 1.3.1) |
| 5.4 Xata OSS | kind + tilt quickstart 정리 | 미실측 (Kubernetes 클러스터 필요) |
| 5.5 선택 매트릭스 | 비교와 판단 | 해당 없음 |
차례
- 5.1 ZFS Snapshot과 Clone: PGDATA를 ZFS dataset에 두고 snapshot과 clone으로 두 번째 PostgreSQL을 기동하는 절차
- 5.2 DBLab Engine: ZFS thin clone 위에 branch, commit, switch 워크플로우를 제공하는 Apache 2.0 도구
- 5.3 Dolt와 Doltgres: 저장 구조가 Git인 데이터베이스. branch뿐 아니라 diff와 머지도 지원하는 유일한 선택지
- 5.4 Xata OSS와 Kubernetes: CloudNativePG와 OpenEBS 위에서 블록 수준 CoW branching을 제공하는 오픈소스 플랫폼
- 5.5 온프레미스 선택 매트릭스: 다섯 접근 방식의 요구 인프라, 호환성, 라이선스 비교와 상황별 추천
읽기 전에 정리할 용어
이 Part에서 "thin clone"은 원본과 블록을 공유하면서 변경분만 별도로 저장하는 사본을 뜻합니다. "snapshot"은 특정 시점의 읽기 전용 고정점입니다. "clone"은 snapshot에서 생성되며 쓰기가 가능한 dataset입니다. ZFS, DBLab, Xata 모두 이 두 단어를 같은 뜻으로 사용합니다. Dolt만 다릅니다. Dolt의 branch는 파일시스템 개념이 아니라 commit 그래프 위의 포인터입니다.