Database Branching 총론
운영 서비스를 유지하면서 개발과 검증에 필요한 데이터 환경을 어떻게 준비할지 다룹니다. 이 영역에서는 branch라는 제품명보다 필요한 데이터의 범위와 기준 시점을 먼저 살펴봅니다. 쓰기 격리와 결과 반영 절차도 함께 살펴봅니다. Snapshot과 clone의 선례부터 구현 계층과 제품 비교를 거쳐 선택 기준을 살펴봅니다. 이어서 운영 활용과 복구 검증까지 다룹니다. 제품과 공개 자료의 기준일은 2026-09-30입니다.
여러 제품에 공통으로 적용할 판단 기준은 이 총론에서 설명합니다. docs-neon은 Neon의 아키텍처와 실습 상세를 다룹니다. Neon의 저장 구조를 더 깊게 읽으려면 Neon 아키텍처로 이동합니다. 기존 노트와 겹치는 구현 설명은 짧게 요약하고 해당 장으로 연결합니다. 제품별 출시 단계와 제공 범위를 살펴볼 때는 이 영역의 기준일도 함께 확인합니다.
학습 구성
3분 요약
- Branch라는 이름 아래 빈 DB 생성, schema 배포, backup 복원이 공존합니다. copy-on-write(CoW)도 포함됩니다. 제품 이름과 생성 모드를 함께 확인합니다.
- 생성 시간이 데이터 크기와 무관하다는 주장은 조건부입니다. 일부 메타데이터 작업과 SQL 접속 준비, 첫 쿼리 실행을 구분합니다.
- 초기 데이터를 공유해도 비용은 남습니다. Compute, 변경 데이터, 보존 이력을 나누어 살펴봅니다. 부모의 변경으로 유지되는 공간도 확인합니다.
- PITR는 복구 목적을 나타냅니다. 보존 기간은 선택 가능한 과거 범위입니다. 허용할 데이터 손실의 시간 목표인 RPO와 구분합니다.
- 데이터 3-way 머지, schema 배포, SQL
MERGE는 서로 다른 동작입니다. 쓰기 가능한 사본을 얻었다는 사실만으로 운영 반영 방법을 정하지 않습니다. - 데이터 쓰기 격리가 자원과 보안 격리까지 보장하지는 않습니다. 인증, 네트워크, 외부 자격증명과 공유 자원을 각각 평가합니다.
- Clone의 존재만으로 독립 백업을 확보했다고 판단하지 않습니다. 공유 파일과 원본 의존성, 계정과 리전의 장애 범위를 확인합니다.
- 동일 조건의 측정과 복구 시험이 없는 제품 종합 순위는 미확인으로 남깁니다. 공개 기능과 고객 사례를 근거로 요구별 검토 후보를 정합니다.
전체 차례
전체 구성은 6 Part, 25장입니다.
- Part 1. 개념과 역사: 데이터 준비 비용, 인접 개념, 선례 기술과 branch 제품의 연대기를 다룹니다.
- Part 2. 구현 계층과 변경 관리: 공유 단위, 일관된 분기점, 준비 시간과 자원 비용, 머지와 운영 반영을 다룹니다.
- Part 3. 제품 관계와 기능 비교: 회사와 기술 계보를 구분하고 생성 모드별 기능과 제공 범위를 비교합니다.
- Part 4. 관점별 선택 기준: 개발과 운영, 온프레미스, AI Agent 환경의 요구에 따라 검토 후보를 정합니다.
- Part 5. 운영 환경에서의 활용: Preview, 리허설, 복구, 분석, 환경 전환, 마스킹, 재현성과 agent 작업을 다룹니다.
- Part 6. 운영 검증과 현행화: 수명과 비용, 보안과 복구 경계, 실습 결과와 출처의 갱신 방법을 다룹니다.