7.4 자주 묻는 질문
학습 중에 반복해서 나오는 질문을 모았습니다. 답은 공식 문서와 소스 저장소 문서에 근거해 작성했습니다. 문서가 명시하지 않은 부분에는 조건을 붙였습니다. 각 답의 끝에는 자세한 설명이 있는 장을 적었습니다.
branch를 만들면 부모 branch의 성능이 떨어집니까?
Neon 문서는 branch의 쓰기가 delta로 저장되며 부모의 성능에 영향을 주지 않는다고 설명합니다. 저장 구조상 자식 timeline은 자기 layer 파일에만 씁니다. 부모 timeline의 layer는 읽기만 합니다. 다만 같은 pageserver가 두 timeline의 GetPage 요청을 함께 처리합니다. 따라서 자체 호스팅에서 pageserver 자원이 부족하면 두 compute 모두 느려집니다. 클라우드 서비스에서는 이 부분을 운영자가 책임집니다. 2.4
branch는 데이터를 복사합니까?
복사하지 않습니다. 새 timeline은 ancestor_timeline_id와 ancestor_lsn만 기록합니다. 요청한 페이지가 자기 layer에 없으면 부모 timeline에서 읽습니다. logical size는 부모와 같게 표시되지만 physical size는 자식이 쓴 만큼만 늘어납니다. 3.4
왜 branch 생성 시간이 데이터 크기와 무관합니까?
생성 작업이 메타데이터를 기록하는 작업이기 때문입니다. pageserver API의 timeline 생성 요청은 새 timeline id, 부모 id, 분기 LSN을 받습니다. 그런 다음 timeline 디렉터리와 메타데이터만 만듭니다. 부모의 layer 파일은 읽거나 복사하지 않습니다. neon-lab에서 측정하면 수 초 안에 끝납니다. 클라우드 서비스 문서도 크기와 관계없이 대략 1초라고 설명합니다. 다만 새 branch에 compute를 연결해 첫 쿼리를 실행하기까지는 compute 기동 시간이 더해집니다. 3.2
branch의 변경을 부모로 머지할 수 있습니까?
Neon에는 데이터 머지 기능이 없습니다. branch는 실험과 검증을 위한 공간입니다. 결과를 부모에 반영할 때 스키마는 neon branches schema-diff로 차이를 확인합니다. 그런 다음 마이그레이션 도구로 다시 적용합니다. 데이터는 애플리케이션 경로나 pg_dump로 옮깁니다. Git처럼 머지를 지원하는 것은 Dolt와 Doltgres입니다. dolt_merge()가 행 단위로 충돌을 감지합니다. DBLab의 branch도 snapshot 계보를 나누는 것이며 머지는 아닙니다. 4.3, 5.3
history window를 넘긴 시점으로 branch를 만들 수 있습니까?
만들 수 없습니다. history window는 pageserver가 옛 page version을 GC하지 않고 보존하는 기간입니다. 이 기간을 벗어난 LSN은 재구성할 수 없습니다. Free 플랜은 최대 6시간 또는 데이터 변경 1GB 중 먼저 도달하는 쪽까지입니다. 쓰기가 많으면 6시간보다 훨씬 짧아집니다. Launch 플랜은 최대 7일, Scale 플랜은 최대 30일입니다. 더 오래 보존해야 하는 시점은 snapshot으로 만들어 두고 expires_at을 조정합니다. 4.4
Neon Local은 오프라인에서 동작합니까?
동작하지 않습니다. Neon Local은 클라우드 프로젝트에 프록시로 연결하는 도구입니다. 컨테이너를 시작할 때 임시 branch를 만들며, NEON_API_KEY와 NEON_PROJECT_ID가 필요합니다. 블로그는 오프라인 모드를 검토 중이라고만 밝혔습니다. 네트워크 없이 branching을 실습하려면 neon-lab이나 cargo neon을 씁니다. 3.5
자체 호스팅으로 production을 운영할 수 있습니까?
upstream은 권장하지 않습니다. docker-compose/README.md는 이 구성이 이미지 테스트용이라고 설명합니다. 실제 시스템에 배포할 수 있는 구성은 아니라고 명시합니다. 또한 이 구성에는 storage controller가 없어 compute를 재구성할 수 없다고 설명합니다. 공개 범위를 오해하기 쉬운데, storage controller와 proxy, autoscaler-agent는 소스가 공개되어 있습니다. 비공개인 것은 Neon Cloud의 콘솔과 완성된 control plane 서비스, 그리고 이들을 묶어 배포하는 turnkey 구성입니다. 학습과 실험에는 제약이 없습니다. 다만 운영 수준으로 배포하려면 compute 오케스트레이션과 정지, 재기동을 담당하는 계층을 직접 만들어야 합니다. 3.6
Neon compute의 WAL은 vanilla PostgreSQL과 호환됩니까?
호환되지 않습니다. core_changes.md는 heap WAL 레코드에 t_cid 필드를 추가했다고 명시합니다. 이 때문에 WAL 포맷이 vanilla와 다릅니다. 따라서 Neon compute의 WAL을 일반 PostgreSQL standby로 전송하는 물리 복제는 불가능합니다. 다른 시스템과는 논리 복제나 dump로 연동합니다. 2.6
대용량 데이터베이스에서도 branch 생성이 빠릅니까?
생성 자체는 메타데이터 작업이므로 크기와 무관합니다. 다만 branch에서 처음 실행하는 쿼리는 필요한 페이지를 pageserver에서 가져와야 합니다. 따라서 로컬 캐시가 비어 있는 새 compute에서는 첫 실행이 느립니다. Aurora clone과 Tiger Cloud fork도 같은 특성이 있습니다. Tiger의 경우 copy-on-write 방식인 Fluid Storage fork는 문서가 분 단위로 설명하고, 백업과 WAL 적용으로 만드는 기존 복원은 WAL 양에 좌우된다고 설명합니다. 어느 쪽이든 데이터 크기만으로 시간을 예측하기는 어렵습니다. 6.2
read replica와 branch는 무엇이 다릅니까?
read replica는 같은 branch의 저장소를 읽는 read-only compute입니다. 부모와 같은 timeline을 보므로 쓰기가 불가능합니다. safekeeper가 최신 변경을 알려 주므로 결국 부모와 같은 상태로 수렴합니다. branch는 분기 LSN 이후의 독립된 timeline입니다. 쓰기가 가능하며 부모의 이후 변경은 받지 않습니다. 읽기 부하 분산에는 replica를, 실험에는 branch를 사용합니다. 2.5
schema-only branch는 왜 reset from parent가 안 됩니까?
schema-only branch는 부모와 timeline 관계가 없는 독립 root branch입니다. reset from parent는 자식 timeline을 부모의 최신 LSN에서 다시 분기하는 동작입니다. 하지만 root branch에는 부모가 없습니다. 같은 이유로 root branch 개수 제한(Free 3개, Launch 5개, Scale 25개)을 소비합니다. 4.5
Aurora clone과 Neon branch는 무엇이 다릅니까?
둘 다 스토리지 계층의 copy-on-write입니다. 차이는 세 가지입니다. Aurora는 클러스터 단위로 clone을 만듭니다. CoW clone은 15개까지이며 이후에는 full copy로 전환됩니다. Neon은 플랜별 branch 수 안에서 branch 안에 branch를 제한 없이 만듭니다. 특정 LSN이나 시각을 지정해 분기할 수도 있습니다. Aurora clone은 생성 후 DB 인스턴스를 별도로 추가해야 합니다. CLI 옵션도 point-in-time restore 명령의 일부입니다. 반면 Neon은 branch 생성과 compute 부착을 한 명령으로 처리합니다. 1.2, 6.5
macOS에서 ZFS thin clone을 실습할 수 있습니까?
권장하지 않습니다. ZFS는 커널 모듈이 필요합니다. Docker Desktop이나 Colima의 Linux VM 안에서도 모듈을 로드하기 어렵습니다. 5.1은 Linux 서버를 기준으로 작성했고, 이 노트에서는 직접 실행하지 않았습니다. macOS에서 thin clone 개념을 직접 확인하려면 Doltgres(5.3)나 neon-lab(Part III)이 대안입니다. 5.1
DBLab Engine은 어떤 PostgreSQL에 붙을 수 있습니까?
DBLab 문서는 자체 관리 PostgreSQL을 소스로 지원한다고 설명합니다. AWS RDS, GCP Cloud SQL, Supabase, Timescale 등 관리형 서비스도 지원합니다. 소스 쪽에는 ZFS나 Docker가 필요하지 않습니다. DBLab 서버가 있는 Linux 호스트에는 ZFS 또는 LVM이 필요합니다. 데이터는 physical 모드(pg_basebackup, WAL-G, pgBackRest)로 받습니다. logical 모드(dump/restore)도 지원합니다. PostgreSQL 10부터 18까지 지원합니다. 5.2
Databricks 인수 뒤 Neon 서비스는 어떻게 됩니까?
2025년 Neon이 Databricks에 합류했습니다. Neon의 아키텍처는 Lakebase Postgres라는 이름으로 제공됩니다. 제공 플랫폼은 Neon과 Databricks입니다. Neon 문서에 따르면 두 플랫폼의 코어 기능은 같습니다. 해당 기능은 branching, autoscaling, scale to zero, read replica, PITR입니다. Neon은 앱 백엔드(Auth, Data API, Object Storage 등)에 초점을 둡니다. Databricks는 Lakehouse와 Unity Catalog 연동에 초점을 둡니다. 오픈소스 저장소는 계속 갱신되고 있습니다. 하지만 control plane 공개 계획은 문서에 없습니다. 1.3, 6.3
학습을 마쳤는지 어떻게 확인합니까?
위 질문들에 문서를 보지 않고 답할 수 있어야 합니다. 또한 neon-lab에서 삭제 사고 재현과 과거 LSN branch 복구를 10분 안에 끝내야 합니다. 두 조건을 충족하면 이 노트의 목표에 도달한 것입니다. 그다음 단계는 팀 환경에 맞게 도입 여부를 판단하는 것입니다. 6.5와 5.5가 그 판단의 틀을 제공합니다.