본문으로 건너뛰기

Neon & Database Branching

데이터베이스를 git branch처럼 나눠 쓰는 일은 오래전부터 스토리지 스냅샷으로 가능했습니다. 그러나 이를 데이터베이스 제품의 기본 동작으로 만든 것은 Neon이 처음이었습니다. 이 노트는 Neon의 storage 엔진을 Docker로 직접 실행하는 과정을 담습니다. branch를 만들고 여러 방식으로 다뤄 보면서 아키텍처를 익힙니다. 또한 2026년 시점에 branching을 제공하는 다른 제품을 살펴봅니다. 온프레미스에서 같은 효과를 구현하는 방법까지 한 흐름으로 정리합니다.

목표는 "branch가 왜 1초 만에 만들어지고 왜 공짜가 아닌지"를 설명하는 것입니다. 각 Part는 다음 요소를 조합합니다.

  1. 개념: copy-on-write가 어느 계층에서 일어나는지
  2. 실측: 이 노트의 실습 환경에서 실제로 실행하고 기록한 명령과 출력
  3. 제약: 문서만 읽으면 놓치는 조건과 오류 메시지
  4. 연습 문제: 직접 바꿔 보며 확인할 과제

3분 요약​

  • Neon의 branch는 timeline입니다. 부모 timeline id와 분기 LSN만 기록하며 데이터는 복사하지 않습니다. 이 노트의 실습에서 62 MB 테이블이 있는 데이터베이스의 branch를 생성하는 데 0.07초가 걸렸습니다.
  • compute는 stateless PostgreSQL입니다. durable state는 safekeeper(WAL quorum), pageserver(page 재구성), object storage에 있습니다. commit은 safekeeper quorum ack로 확정됩니다.
  • pageserver는 WAL을 key와 LSN 두 축의 layer 파일로 다시 정리합니다. 과거 LSN의 page를 재구성할 수 있습니다. 따라서 branch, PITR, time travel은 같은 메커니즘을 사용합니다.
  • branch의 logical size는 부모와 같습니다. physical size는 분기 이후 변경분만 늘어납니다. 비용은 history 보존 기간과 branch마다 붙는 compute에서 발생합니다.
  • Neon 저장 엔진은 Apache 2.0이지만 control plane은 비공개입니다. compose로 실행한 것은 "branch 있는 저장 엔진"이지 "서비스"가 아닙니다.
  • 2025년 Databricks가 Neon을 인수했습니다. 같은 엔진은 Lakebase Postgres라는 이름으로 Neon과 Databricks 양쪽에서 제공됩니다.
  • Xata는 블록 스토리지 계층에서 copy-on-write를 수행합니다. Aurora와 Tiger Cloud는 자체 스토리지 볼륨에서, DBLab과 ZFS는 파일시스템에서 수행합니다. PlanetScale Postgres와 Supabase의 branch는 데이터를 복사하지 않는 독립 인스턴스에 가깝습니다.
  • Neon에는 branch를 부모로 머지하는 기능이 없습니다. 스키마는 schema-diff로 비교하고 데이터는 직접 옮깁니다. Dolt 계열만 머지를 제공합니다.
  • 온프레미스에서 가장 현실적인 선택은 ZFS 기반 thin clone과 이를 제품화한 DBLab Engine입니다. Kubernetes 표준화를 추진하는 팀이라면 Xata OSS를 검토합니다.

난이도별 학습 경로​

단계먼저 읽을 Part도달 목표
입문I → IIIbranching이 푸는 문제를 이해하고 로컬에서 branch를 만들어 본다
중급II → IVsafekeeper, pageserver, timeline 구조를 설명하고 CLI와 CI 워크플로우를 설계한다
운영V → VI온프레미스 대안을 비교하고 비용, 성능, 내구성 모델을 평가한다
정리VII용어와 명령을 치트시트로 복습한다

전체 차례​

실습 프로젝트​

neon-lab은 upstream 저장소의 Docker Compose 예제를 학습용으로 정리한 것입니다. MinIO, storage_broker, pageserver, safekeeper 3대, compute 2대를 실행합니다. 도우미 스크립트로 branch를 만들고 상태를 확인합니다.

cd neon-lab
docker compose build compute1
docker compose up -d
./scripts/psql.sh compute1 -c "select version();"
./scripts/branch.sh feature-a
docker compose --profile branch up -d compute2
./scripts/psql.sh compute2 -c "show neon.timeline_id;"

이미지 두 개가 약 9 GB입니다. 첫 pull에는 시간이 걸립니다. Part I을 읽는 동안 미리 받아 두면 좋습니다.

추천 실습 순서​

  1. 3.1에서 compose를 실행하고 orders 테이블 50만 건을 적재합니다.
  2. 3.2에서 branch를 만들고 두 compute의 쓰기가 격리되는지 확인합니다.
  3. 3.3에서 DELETE를 실행한 뒤 삭제 직전 LSN으로 branch를 만들어 복구합니다.
  4. 3.4에서 layer 파일과 MinIO 버킷을 열어 copy-on-write를 직접 확인합니다.
  5. 5.3에서 Doltgres를 실행해 branch와 머지를 비교합니다.
  6. 4.3의 마이그레이션 리허설을 로컬 branch에서 재현합니다.

기준과 범위​

  • Neon 저장 엔진: ghcr.io/neondatabase/neon:latest, compute는 PostgreSQL 17.5 (2026-09 기준 이미지)
  • Neon 클라우드 서비스 사실: 2026년 9월 공식 문서 기준. 플랜과 가격은 변경될 수 있어 본문에 시점을 적었습니다.
  • 다른 제품: 각 공식 문서와 블로그를 인용했습니다. 본문 끝 참고 목록에 출처를 남겼습니다.
  • 실측 환경: Apple Silicon macOS, Docker VM 2 vCPU 12 GB. 수치는 이 환경을 기준으로 합니다. 절대값보다 비율과 순서에 의미를 둡니다.
  • 범위 밖: Neon 클라우드 콘솔 조작 화면, Databricks 쪽 Lakebase 사용법, 각 제품의 가격 비교

주요 공식 자료​