본문으로 건너뛰기

1.3 2026년 Branching DB 지형

2026년 현재 "branching"이라는 단어를 내세우는 데이터베이스 제품은 열 개가 넘습니다. 그러나 이 단어가 가리키는 실체는 제품마다 다릅니다. 어떤 제품은 스토리지 수준의 copy-on-write로 데이터까지 순식간에 복제합니다. 어떤 제품은 schema만 복사한 빈 인스턴스를 새로 만들면서 branch라고 부릅니다. 이 장에서는 2026년 9월 시점에 확인한 문서를 기준으로 주요 제품을 한 표에서 비교합니다. 또한 각 제품이 실제로 무엇을 하는지 정리합니다. 이 분야는 빠르게 변하므로 도입 전에는 공식 문서를 다시 확인해야 합니다.

요약​

제품엔진CoW 계층데이터 포함자체 호스팅라이선스
Neon (Lakebase Postgres)PostgreSQL 14~18 (패치)pageserver page 버전포함엔진만 공개, control plane 비공개Apache 2.0 (엔진)
Xatavanilla PostgreSQL (CNPG)블록 스토리지 (NVMe-oF)포함Kubernetes 기반 OSSApache 2.0 (스토리지 엔진 제외)
PlanetScale PostgresPostgreSQL없음 (독립 배포)빈 branch 미포함, backup/PITR 복원 branch 포함없음상용
Supabase Branching 2.0PostgreSQL없음 (새 프로젝트 인스턴스)기본 미포함, 옵션플랫폼 기능상용 (플랫폼)
Dolt / Doltgres독자 엔진 (MySQL / PG 프로토콜)Prolly tree 구조 공유포함단일 바이너리Apache 2.0
DBLab EnginePostgreSQL 10~18 (무수정)ZFS / LVM포함Linux + ZFS 또는 LVMApache 2.0
Tiger Cloud forkPostgreSQL + TimescaleDBFluid Storage포함없음상용
Aurora cloneAurora PostgreSQL / MySQL스토리지 볼륨포함없음상용 (AWS)
Prisma PostgresPostgreSQLCoW 주장 (세부 미확인)포함 (문서 기준)없음상용
TursolibSQL (SQLite 계열)플랫폼 기능 (세부 미확인)확인 필요libSQL은 OSS혼합

표에는 사실만 적었습니다. 어떤 제품이 적합한지는 아래 산문과 1.4 선택 기준과 흔한 오판에서 판단합니다.

Neon과 Lakebase​

Neon은 "branch your database like you branch code"라는 표현을 널리 알린 제품입니다. PostgreSQL의 저장 계층을 pageserver와 safekeeper로 분리합니다. branch는 특정 LSN을 조상으로 갖는 timeline으로 구현했습니다. 생성 시간은 데이터 크기와 무관합니다. history window 안에 있는 자식 branch의 추가 저장 공간은 쓰기로 발생한 delta만큼입니다. 가격 문서에 따르면 history window를 벗어난 자식 branch는 부모와의 공유 혜택이 사라집니다. 따라서 root branch처럼 과금됩니다.

2025년 Neon은 Databricks에 인수되었습니다. 이후 Neon이 만든 서버리스 PostgreSQL 아키텍처는 "Lakebase Postgres"라는 이름으로 두 곳에서 제공됩니다. neon.com에서는 앱과 agent를 위한 백엔드로 제공됩니다. 여기에는 Auth, Data API, Object Storage, Functions, AI Gateway가 포함됩니다. Databricks 안에서는 Lakehouse, Unity Catalog와 연동되는 기업용 PostgreSQL로 판매됩니다. Neon 문서는 두 서비스의 주요 데이터베이스 기능이 같다고 설명합니다. 해당 기능은 branching, autoscaling, scale-to-zero, read replica, PITR입니다. 2026년 8월에도 Electric이 Databricks에 합류해 Neon 팀에 통합된다는 발표가 있었습니다.

오픈소스 범위에는 주의해야 합니다. 저장소 neondatabase/neon은 Apache 2.0이고 pageserver, safekeeper, compute 이미지가 공개되어 있습니다. 반면 프로젝트와 branch를 관리하는 control plane은 비공개입니다. 저장소의 docker-compose 예제도 "이미지 테스트용이며 사용 가능한 시스템을 배포하려는 것이 아니다"라고 명시합니다. 그래도 학습 목적으로 pageserver API를 직접 호출해 branch를 만드는 실습은 가능합니다. Part III에서 직접 실습합니다.

플랜은 Free, Launch, Scale 세 가지이며 AI 플랫폼용 Agent 플랜도 예고되어 있습니다. history 보존 범위(history window)는 Free가 최대 6시간 또는 변경량 1 GB 중 먼저 도달하는 범위입니다. Launch는 최대 7일, Scale은 최대 30일입니다. 이 범위가 과거 시점 branch와 instant restore가 도달할 수 있는 한계입니다.

Xata​

Xata는 Neon과 다른 계층을 선택했습니다. PostgreSQL을 수정하지 않고 그 아래의 블록 스토리지를 NVMe-oF로 네트워크에 노출합니다. 그런 다음 블록 수준에서 copy-on-write branching을 수행합니다. 스택은 Kubernetes 위의 CloudNativePG operator와 OpenEBS(Mayastor)입니다. Xata는 2025년 5월 이 구조로 비공개 베타를 시작했습니다. 이후 주요 부품인 SQL gateway, branch operator, control plane 서비스, 인증, CLI, scale-to-zero CNPG 플러그인을 Apache 2.0으로 공개했습니다. 자체 스토리지 엔진 Xatastor와 멀티 리전 배포 코드는 비공개로 남았습니다.

로컬에서는 kind로 Kubernetes 클러스터를 만들고 tilt up으로 부품을 실행합니다. 단일 PostgreSQL 인스턴스만 필요한 경우에는 Kubernetes 오버헤드 때문에 권하지 않는다고 스스로 밝힙니다. 관련 오픈소스로 pgroll(무중단 schema 마이그레이션)과 pgstream(DDL 포함 replication)이 있습니다. 5.4 Xata OSS와 Kubernetes에서 다룹니다.

PlanetScale Postgres​

PlanetScale은 MySQL과 Vitess를 기반으로 branch와 deploy request 워크플로우를 만든 회사입니다. 2025년 PostgreSQL 지원을 시작했습니다. 2026년 문서에 따르면 PostgreSQL branch는 "격리된 독립 데이터베이스 배포"입니다. branch 사이에는 데이터 복제가 없습니다. 빈 branch에 데이터가 필요하면 pg_dump/pg_restore나 pgcopydb로 직접 옮겨야 합니다. 문서에 따르면 backup이나 PITR에서 복원해 만든 branch는 schema와 데이터를 함께 보유합니다. 개발 branch는 데이터베이스당 최대 100개입니다. 성능이 제한된 PS-DEV 인스턴스에서 실행됩니다.

Vitess의 deploy request는 schema 변경을 큐에 넣고 충돌을 검사한 뒤 운영에 적용합니다. 이 기능은 PostgreSQL branch에는 적용되지 않습니다. 문서는 PostgreSQL에서는 branch에 직접 접속해 DDL을 실행해야 한다고 설명합니다. 운영에도 같은 작업을 반복해야 합니다. 또한 branch 간 schema 변경을 자동으로 머지하는 방법이 없다고 설명합니다. 따라서 PlanetScale Postgres의 branch는 copy-on-write thin clone이 아닙니다. "이름이 붙은 별도 개발 환경"에 가깝습니다.

Supabase Branching 2.0​

Supabase branch는 "프로젝트의 복사본에서 데이터를 뺀 것"입니다. branch를 만들면 새 PostgreSQL 인스턴스가 생깁니다. 마이그레이션 파일을 실행해 schema를 맞춘 뒤 seed 파일로 데이터를 넣습니다. 2025년 7월 Branching 2.0에서는 Git 연동 없이도 branch를 만들도록 바뀌었습니다. 대시보드, CLI, Management API를 이용합니다. 2026년 5월 4일부터 Git 없는 branching이 기본값이 되었습니다. 대시보드의 SQL Editor에서 변경한 뒤 schema diff를 검토해 머지하는 흐름입니다.

데이터는 기본적으로 복사되지 않습니다. 대시보드에서 branch를 만들 때는 "include data" 옵션을 씁니다. 다만 문서에 따르면 Point-in-Time Recovery add-on이 있는 프로젝트에서만 활성화됩니다. 추가 compute와 disk 비용도 부과됩니다. GitHub 연동에서는 seed 파일을 사용할 수 있습니다. branch는 PR과 함께 사라지는 preview branch와 오래 유지하는 persistent branch로 나뉩니다. Supabase branch의 가치는 데이터베이스 하나에 그치지 않습니다. Auth, Storage, Edge Functions까지 포함한 백엔드 전체를 PR마다 격리합니다.

Dolt와 Doltgres​

Dolt는 "Git for Data"를 내세운 데이터베이스입니다. 테이블을 Prolly tree에 저장해 branch 사이에서 변경되지 않은 노드를 공유합니다. branch, merge, diff, push, pull을 SQL 함수와 CLI로 제공합니다. 다른 제품에는 없는 row 단위 세 방향 머지도 가능합니다. MySQL 프로토콜을 사용하는 Dolt가 본체입니다. PostgreSQL 프로토콜을 구현한 Doltgres는 2025년 베타에 도달했습니다. Doltgres 문서는 성능이 vanilla PostgreSQL의 약 5배 느리다고 밝힙니다. SQL 호환 테스트 통과율은 약 91%입니다.

2026년 DoltHub는 agent 워크플로우를 전면에 내세우고 있습니다. agent마다 branch를 제공해 쓰기를 격리한 뒤 사람이 검토해 머지하는 모델을 소개했습니다. 이를 측정하는 BranchBench라는 벤치마크도 소개했습니다. 단일 바이너리로 설치할 수 있고 Docker 이미지도 있어 로컬 실습 장벽이 가장 낮습니다. 5.3 Dolt와 Doltgres에서 실행합니다.

DBLab Engine​

Postgres.ai의 DBLab Engine은 온프레미스와 클라우드 어디에나 설치할 수 있는 thin clone 도구입니다. ZFS(기본) 또는 LVM 위에서 스냅샷을 관리합니다. 요청이 들어오면 clone을 만들고 컨테이너에서 PostgreSQL을 실행합니다. 원본은 자체 관리 PostgreSQL이든 RDS, Cloud SQL 같은 관리형 서비스든 무관합니다. 물리 모드(pg_basebackup, WAL-G, pgBackRest)와 논리 모드(dump/restore)로 데이터를 가져옵니다. 4.0부터 dblab branch, dblab commit, dblab switch, dblab log 명령으로 Git 어휘를 제공합니다. 라이선스는 Apache 2.0이고 유료 지원판이 따로 있습니다. 운영 중인 PostgreSQL을 바꾸지 않고 branching을 도입하려는 팀에 가장 현실적인 온프레미스 선택지입니다.

Tiger Cloud fork​

Tiger Data(구 Timescale)의 Tiger Cloud는 서비스 단위의 fork를 제공합니다. tiger service fork <service_id> 명령에 --now, --last-snapshot, --to-timestamp 중 하나를 지정합니다. 각각 현재, 마지막 스냅샷, 특정 시점의 fork를 만듭니다. Fluid Storage라는 자체 스토리지에서는 copy-on-write로 동작합니다. 부모와 달라진 청크만 과금됩니다. 무료 서비스에서는 30~90초가 걸립니다. 표준 서비스에서는 크기에 따라 5~20분 이상 걸린다고 안내합니다. 자체 호스팅은 없습니다.

Aurora clone​

Aurora는 관리형 서비스 가운데 가장 오래전부터 copy-on-write clone을 제공해 왔습니다. restore-db-cluster-to-point-in-time 명령에 --restore-type copy-on-write를 지정하면 스토리지 볼륨 수준에서 clone이 만들어집니다. copy-on-write clone은 15개까지 만들 수 있고 그다음부터는 full copy가 됩니다. 같은 리전 안에서만 가능하며 clone에서 다시 clone을 만드는 것도 허용됩니다. 개발자 도구보다는 인프라 프로비저닝 작업에 가깝습니다. 생성 후 DB 인스턴스를 따로 연결해야 합니다.

그 외​

Prisma Postgres는 PR마다 무료 branch를 제공합니다. 1초 안에 copy-on-write branch를 만든다고 소개합니다. 이 글을 쓰는 시점에는 스토리지 구현 세부를 확인하지 못했습니다. 따라서 표에 "세부 미확인"으로 적었습니다. Turso는 SQLite 계열 libSQL을 기반으로 한 엣지 데이터베이스입니다. 플랫폼에서 데이터베이스 branch 기능을 제공합니다. 다만 이 노트의 범위(PostgreSQL 운영)와 거리가 있어 이름만 적습니다. PandaStack처럼 PostgreSQL VM 전체를 API로 복제해 branch라고 부르는 서비스도 있습니다. 이 경우 생성에 30~90초가 걸리며 copy-on-write가 아닙니다.

지형을 읽는 방법​

제품을 세 줄기로 나누면 이해하기 쉽습니다. 첫째는 스토리지 분리형입니다. Neon, Xata, Tiger Cloud, Aurora가 여기에 속합니다. 데이터를 포함한 branch를 복사 없이 만듭니다. 다만 "빨리"의 의미는 두 단계로 나누어 살펴봐야 합니다. 스토리지 메타데이터를 분기하는 시간과 접속 가능한 데이터베이스가 준비되는 시간은 다릅니다. Neon의 분기 시간은 이 노트의 실측에서 0.07초였습니다. compute 기동에는 수 초가 더 걸립니다. Xata는 블로그 기준 1~2초입니다. Tiger Cloud는 무료 서비스에서 30~90초, 표준 서비스에서 5~20분 이상 걸립니다. Aurora는 clone 볼륨을 만든 뒤 DB 인스턴스를 따로 생성해야 접속할 수 있습니다. 둘째는 워크플로우형입니다. PlanetScale과 Supabase가 여기에 속합니다. branch는 별도 인스턴스이며 데이터는 따로 채웁니다. 이들의 강점은 데이터 복제보다 schema 변경을 검토하고 머지하는 절차에 있습니다. 백엔드 전체를 격리하는 것도 강점입니다. 셋째는 버전 관리형입니다. Dolt 계열만 여기에 속하며 데이터 자체를 Git처럼 다룹니다.

온프레미스 관점에서는 선택지가 다시 나뉩니다. DBLab Engine과 ZFS 직접 구성은 현재 운영하는 PostgreSQL을 그대로 두고 옆에 연결합니다. Xata OSS는 Kubernetes 위에 새 스택을 구축하는 방식입니다. Neon 자체 호스팅은 저장소 코드로 가능합니다. 하지만 control plane을 직접 만들어야 하며 업스트림도 권하지 않습니다. 이 차이는 Part V에서 실제 절차로 확인합니다.

연습 문제​

  1. 위 표에서 "데이터 포함" 열이 "미포함"인 제품을 고릅니다. 그 제품이 branch라는 단어로 실제 제공하는 가치가 무엇인지 한 문단으로 적습니다.
  2. 팀이 이미 Kubernetes를 운영한다면 Xata OSS와 DBLab Engine 중 어느 쪽의 도입 비용이 낮을지 비교합니다. 필요한 인프라 항목을 나열합니다.
  3. Aurora clone의 15개 제한과 Neon 플랜별 포함 branch 수(Free/Launch 10개, Scale 25개)를 비교합니다. 가격 문서에 따르면 유료 플랜은 포함 수를 넘는 branch를 시간 비례로 과금합니다. Free의 hard limit 여부는 따로 확인해야 합니다. 두 제한의 성격이 어떻게 다른지 설명합니다.

참고​