본문으로 건너뛰기

7.3 학습 로드맵과 읽을 자료

이 노트는 Part 순서대로 읽어도 됩니다. 다만 쓸 수 있는 시간에 따라 경로를 달리 잡는 편이 효율적입니다. 아래 세 경로는 모두 Part III의 Docker 실습을 포함합니다. branch를 직접 만들어 보지 않으면 Part II의 timeline과 LSN 설명은 추상적으로만 남습니다.

시간별 학습 경로​

기간읽는 순서실습도달 목표
1주I → II(2.1, 2.2, 2.4) → III(3.1, 3.2) → IV(4.1)neon-lab 기동, branch 1개 생성, 부모/자식 쓰기 격리 확인branch가 왜 데이터 크기와 무관하게 만들어지는지 설명
2주1주 경로 + II(2.3, 2.5, 2.6) → III(3.3, 3.4) → IV(4.2, 4.3, 4.4) → VI(6.1, 6.4)과거 LSN branch, physical size 관찰, PR별 branch 워크플로우 설계팀의 dev/test 환경에 branching을 적용할 때의 비용과 제약을 정리
1개월전체 Part 순서III 전체, V(5.2 또는 5.3 중 하나 이상), Neon Free 플랜에서 CLI 실습온프레미스 대안까지 비교해 도입 여부를 판단하고 발표 자료로 정리

1주 경로에서는 2.3(Pageserver와 Layer 파일)을 건너뜁니다. layer 구조를 몰라도 branch를 만들고 쓸 수 있기 때문입니다. 대신 3.4에서 physical size가 변하는 것을 확인한 뒤에는 2.3을 이해하기 쉽습니다. 2주 경로부터는 순서를 바꿔 2.3을 먼저 읽습니다.

실습 순서​

  1. 3.1에서 compose를 기동한 뒤 scripts/status.sh로 tenant와 timeline을 확인합니다.
  2. 3.2에서 테이블을 만들고 branch를 생성합니다. compute2로 접속해 같은 데이터가 보이는지 확인한 뒤 쓰기가 격리되는지 확인합니다.
  3. 3.3에서 행을 삭제한 뒤 삭제 전 LSN으로 branch를 만들어 삭제한 행을 되찾습니다.
  4. 3.4에서 timeline API의 current_physical_size와 MinIO 버킷을 비교합니다.
  5. Neon Free 플랜에 가입한 뒤 4.1의 CLI 명령을 같은 순서로 반복합니다. 자체 호스팅과 클라우드의 차이가 여기서 드러납니다.
  6. Linux 서버가 있으면 5.1, 없으면 5.3을 실습합니다.

읽을 자료​

Neon 공식 문서​

  • Architecture overview: compute, safekeeper, pageserver, object storage의 역할을 설명합니다. 쓰기/읽기 경로도 가장 짧게 설명합니다. Part II를 읽기 전에 한 번, 읽은 뒤에 다시 봅니다.
  • Branching: branch의 정의, history window, reset, restore, expiration을 한 페이지에서 설명합니다. Part IV의 기준 문서입니다.
  • Plans: 플랜별 CU 범위, branch 수, history window 상한. 비용 계산의 근거입니다.
  • Autoscaling algorithm: CPU, 메모리, LFC working set 세 지표로 목표 CU를 정하는 식을 제시합니다. 2.5의 근거입니다.
  • Schema-only branches: schema-only branch가 독립 root branch라는 점과 플랜별 제한은 이 문서에만 있습니다.
  • Neon Local: 로컬 개발용 프록시 컨테이너. 자체 호스팅과 혼동하기 쉬워 3.5에서 따로 다뤘습니다.

neondatabase/neon 저장소 문서​

저장소의 docs/ 아래 문서는 클라우드 서비스 문서보다 오래된 자료입니다. 하지만 저장 구조를 코드 수준으로 설명하는 유일한 자료입니다. 일부 문단에는 TODO와 FIXME가 그대로 남아 있습니다.

  • pageserver-storage.md: layer 파일, L0/L1, branch 생성 시 파일 구조, GC 규칙. 2.3과 2.4의 근거입니다.
  • safekeeper-protocol.md: proposer와 acceptor의 handshake, 복구, VCL, epoch. TLA+ 명세가 spec/에 있습니다.
  • walservice.md: WAL 서비스를 별도 컴포넌트로 구성한 이유를 Q&A로 설명합니다.
  • core_changes.md: PostgreSQL 코어에 적용한 패치 목록을 설명합니다. 각 패치를 없애려는 계획도 제시하며, 2.6의 근거입니다.
  • glossary.md: 7.1의 원본입니다.
  • RFCs: 주요 설계 변경에 관한 결정 기록. 특정 기능이 왜 그렇게 만들어졌는지 찾을 때 봅니다.
  • docker-compose/: neon-lab의 원본. README에는 "이미지 테스트용이고 사용 가능한 시스템 배포용이 아니다"라고 적혀 있습니다.

블로그와 발표​

  • Architecture decisions in Neon (Heikki Linnakangas, 헤이키 린나캉가스, 2022-07): 창업자가 storage와 compute를 나눈 이유를 직접 설명합니다. safekeeper와 pageserver를 별도 계층으로 둔 이유도 설명합니다. 모든 page version을 보존해 PITR을 branching으로 바꾼 발상도 다룹니다. Part II를 읽기 전 첫 자료로 적합합니다.
  • Make yourself at home with Neon Local: Neon Local의 동작 방식과 한계.
  • PGCon 2022 Neon 발표: core_changes.md가 이 발표의 논의를 인용합니다. 발표 자료 원본을 확인하지 못해 링크를 넣지 않았습니다.

논문​

  • Alexandre Verbitski(알렉상드르 베르비츠키) 외, "Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases", SIGMOD 2017: 로그를 스토리지 계층으로 보내고 페이지를 스토리지에서 재구성합니다. 이 설계의 원조입니다. Neon 아키텍처를 읽은 뒤 비교하면 안전하게 이해됩니다.
  • Panagiotis Antonopoulos(파나요티스 안토노풀로스) 외, "Socrates: The New SQL Server in the Cloud", SIGMOD 2019: 로그 서비스와 page server를 분리한 SQL Server Hyperscale 설계입니다. safekeeper와 pageserver의 분리가 Neon만의 발상이 아님을 보여 줍니다.

대안 기술​

  • A New Era of Databases: Lakebase (Databricks, 2025-06, 2026-02 갱신): Databricks가 lakebase를 정의한 글. Neon 인수 뒤 Neon 아키텍처가 어떤 이름으로 불리는지 알 수 있습니다.
  • Neon and Lakebase: Neon의 관점에서 다룬 같은 내용. 두 플랫폼의 공통점과 차이점을 표로 정리합니다.
  • Xata: open source Postgres platform with CoW branching: vanilla PostgreSQL을 그대로 유지하고 블록 스토리지 계층에서 CoW를 구현한 대안. Neon과의 설계 차이를 비교하는 데 좋습니다.
  • DBLab Engine 문서: ZFS 기반 thin clone과 4.0의 branching. 온프레미스에서 현실적인 후보 중 하나입니다. ZFS나 LVM 운영 역량, 데이터 갱신 방식과 허용 RPO, 데이터 크기, 지원 계약 필요 여부에 따라 5.5의 다른 선택지가 앞설 수 있습니다.
  • Prolly Trees (Tim Sehn, 팀 센, 2024-03): Dolt가 branch 간 구조 공유에 사용하는 자료구조. 페이지나 블록이 아닌 트리 노드 수준 CoW의 예입니다.
  • Aurora cloning: copy-on-write protocol 설명과 15개 제한. 관리형 서비스가 CoW 클론을 어떻게 노출하는지 보여 줍니다.

읽는 순서 제안​

  1. Architecture decisions in Neon 블로그
  2. Neon Architecture overview 문서
  3. 이 노트 Part II
  4. pageserver-storage.md와 safekeeper-protocol.md
  5. Aurora 논문, Socrates 논문 순으로 비교
  6. Xata 블로그와 Lakebase 글로 2026년 지형 확인

논문 두 편은 각각 12페이지 안팎입니다. Part II를 먼저 읽으면 용어가 대부분 겹쳐 빠르게 읽힙니다.