Part II. Neon 아키텍처
Neon은 PostgreSQL의 storage 계층을 분리해 네트워크 너머의 별도 서비스로 만든 설계입니다. Compute 노드는 데이터 파일을 보유하지 않는 PostgreSQL 프로세스입니다. 그 아래에는 WAL을 보관하는 Safekeeper, page 버전을 재구성하는 Pageserver, 장기 보관용 object storage가 계층을 이룹니다. Branching, scale to zero, PITR 같은 기능은 모두 이 분리 구조에서 비롯됩니다.
이 Part는 각 구성 요소가 어떤 데이터를 어디까지 책임지는지 설명합니다. 또한 branch가 storage 안에서 실제로 어떤 형태인지 살펴봅니다. Part III에서 Docker로 직접 실행할 때 로그와 API 응답을 해석하려면 이 Part의 용어가 필요합니다.
Storage Broker는 데이터를 저장하지 않습니다. Safekeeper와 Pageserver가 서로 어떤 timeline의 WAL이 어디까지 있는지 알 수 있도록 조정하는 역할만 맡습니다.
이 Part의 장
- 2.1 Compute와 Storage 분리: stateless compute, basebackup tarball, GetPage@LSN, 쓰기와 읽기 경로
- 2.2 Safekeeper와 WAL 내구성: WAL proposer, Paxos quorum, CommitLSN/FlushLSN/VCL, backpressure
- 2.3 Pageserver와 Layer 파일: in-memory layer, L0/L1 delta, image layer, compaction, GC
- 2.4 Timeline과 Branch 내부: ancestor LSN, 읽기 경로의 재귀, logical size와 physical size, history window
- 2.5 Autoscaling과 Scale to Zero: CU, autoscaler-agent, vm-monitor, read replica
- 2.6 Postgres 패치와 제약: core 패치 목록, WAL 포맷 비호환, 확장과 upgrade 제약
읽는 순서
처음이라면 2.1과 2.4만 읽어도 branch가 즉시 만들어지는 이유를 이해할 수 있습니다. 2.2와 2.3은 내구성과 저장 비용을 따질 때 필요합니다. 2.5는 요금과 콜드스타트를 설명할 때 필요합니다. 2.6은 기존 PostgreSQL 운영 지식이 어디서 어긋나는지 확인할 때 봅니다.
이 Part에서 쓰는 이름
Neon 공개 문서는 2026년 기준으로 이 구조를 Lakebase Postgres라고도 부릅니다. Databricks의 Lakebase와 neon.com 서비스가 같은 storage 엔진을 공유하기 때문입니다. 이 노트에서는 오픈소스 저장소와 개발 문서의 용어를 따릅니다. compute, safekeeper, pageserver, timeline이라는 이름은 그대로 씁니다.