Neon Serverless PostgreSQL: 스토리지-컴퓨트 분리와 CoW 브랜칭이 만드는 새로운 OLTP 운영 모델
왜 지금 봐야 하나
2025년 5월 Databricks가 Neon을 약 10억 달러에 인수하면서 서버리스 PostgreSQL이 엔터프라이즈 데이터 플랫폼 맥락에서 재조명됐다. 그러나 Neon의 아키텍처 자체는 인수 전부터 독립적으로 완성도를 높여왔다.
인수 이후 1년 동안 보고된 수치가 있다. 데이터베이스 수는 6,000개에서 70만 개 이상으로 늘었다. 스토리지 비용은 80% 인하됐다($0.35/GB-월). 그리고 의미 있는 통계 하나: 이 기간 생성된 데이터베이스의 약 80%가 AI 에이전트에 의해 만들어졌다(Databricks 발표 기준).
이 숫자들이 흥미로운 이유는 Neon이 전통적인 "인스턴스 예약" 방식의 PostgreSQL이 아니라, 스토리지와 컴퓨트를 완전히 분리한 구조이기 때문이다. 이 구조가 어떻게 동작하는지, 기존 PostgreSQL 운영자 관점에서 무엇이 다른지를 이 글에서 정리한다.
전통적인 PostgreSQL과 무엇이 다른가
전통 모델: 컴퓨트가 스토리지를 소유
표준 PostgreSQL에서 Postgres 프로세스는 로컬 디스크에 직접 데이터 파일을 쓰고 읽는다. shared_buffers에 데이터 페이지를 캐싱하고, WAL(Write-Ahead Log)을 로컬 파일시스템에 쓰고, 체크포인트 시점에 dirty 페이지를 디스크에 플러시한다.
이 구조에서는:
- 컴퓨트 인스턴스가 죽으면 영속 데이터도 그 인스턴스에 묶여 있다.
- 스케일업·다운을 하려면 데이터를 이동하거나 복제해야 한다.
- 유휴 인스턴스도 스토리지를 점유하기 때문에 완전한 "제로 비용 유휴"가 어렵다.
Neon 모델: 스토리지와 컴퓨트가 네트워크로 연결
Neon에서 Postgres 프로세스(컴퓨트)는 영속 상태를 전혀 보유하지 않는다. WAL 레코드는 네트워크를 통해 Safekeeper 클러스터로 스트리밍되고, 데이터 페이지는 Pageserver에서 필요할 때 요청해서 가져온다. 컴퓨트 인스턴스가 완전히 종료되어도 데이터는 Safekeeper와 Pageserver(+ 오브젝트 스토리지)에 안전하게 보존된다.
세 레이어 아키텍처
Neon 아키텍처는 세 독립 레이어로 구성된다.
레이어 1: 컴퓨트 (Compute)
표준 Postgres 바이너리가 실행되는 곳이다. 수정 사항은 두 가지다.
첫째, WAL을 로컬 파일시스템이 아닌 네트워크를 통해 Safekeeper로 전송한다. wal_level = replica 이상이 강제되고, Neon 커스텀 WAL 전송 플러그인이 이 역할을 담당한다.
둘째, 페이지 읽기가 GetPage@LSN 프로토콜로 Pageserver에 요청된다. 로컬 디스크에 데이터 파일이 없고, shared_buffers에 없는 페이지는 RPC로 Pageserver에서 가져온다.
컴퓨트는 완전히 무상태(stateless)다. 재시작하거나 종료해도 데이터 손실이 없다. 유휴 상태일 때 완전히 종료하고(scale-to-zero), 요청이 오면 500ms 이내에 재시작할 수 있다.
레이어 2: Safekeeper (WAL 쿼럼)
Safekeeper는 WAL을 내구성 있게 보관하는 분산 서비스다. 여러 Safekeeper 노드가 쿼럼(통상 3개)을 형성한다. Postgres 트랜잭션은 WAL이 쿼럼 과반수 Safekeeper에 승인(acknowledge)됐을 때 커밋된 것으로 간주된다.
Safekeeper의 역할은 두 가지다.
- 컴퓨트가 만들어내는 WAL 스트림을 받아 내구성 있게 저장한다(임시 버퍼).
- Pageserver가 WAL을 가져갈 때까지 WAL을 보관하고 넘겨준다.
Pageserver가 WAL을 처리하고 오브젝트 스토리지에 업로드한 이후에는 Safekeeper에서 해당 WAL 세그먼트를 제거할 수 있다.
레이어 3: Pageserver (페이지 구체화)
Pageserver는 WAL 레코드를 받아 Postgres 데이터 페이지로 구체화(materialize)하는 서비스다. 특정 LSN(Log Sequence Number) 시점의 페이지를 컴퓨트에서 요청하면, Pageserver는 기준 이미지(base image)와 그 이후의 WAL 델타 레코드를 합산해 해당 LSN 기준의 페이지를 반환한다.
Pageserver는 비덮어쓰기(non-overwriting) 스토리지 포맷을 사용한다. 기존 페이지를 수정하는 대신 새 버전을 덧붙인다. 이 구조가 CoW 브랜칭의 기반이 된다.
페이지 데이터는 레이어 파일(layer file) 형태로 오브젝트 스토리지(S3 등)에 업로드된다. Pageserver는 활성 데이터의 캐시 역할도 한다.
WAL 흐름의 세부 경로
트랜잭션이 커밋되는 순간부터 어떤 일이 일어나는지를 단계별로 살펴본다.
- WAL 생성: Postgres 프로세스가 트랜잭션 변경 사항을 WAL 레코드로 직렬화한다.
- Safekeeper 스트리밍: WAL 레코드가 네트워크를 통해 모든 Safekeeper 노드로 전송된다.
- 쿼럼 승인: 과반수(2/3) Safekeeper가 영속 스토리지에 WAL을 쓰고 승인을 보내면 트랜잭션이 커밋된 것으로 확정된다. 이 시점에 클라이언트에게 커밋 응답이 간다.
- Pageserver 전달: Safekeeper에서 Pageserver로 WAL이 전달된다.
- 페이지 구체화: Pageserver가 WAL 레코드를 처리해 페이지 버전을 업데이트하고, 레이어 파일을 오브젝트 스토리지에 비동기로 업로드한다.
- GetPage@LSN 응답: 컴퓨트에서 특정 페이지의 특정 LSN 버전을 요청하면 Pageserver가 응답한다.
이 경로에서 컴퓨트 인스턴스가 언제 재시작되어도 Safekeeper와 Pageserver에 모든 데이터가 보존되므로 데이터 손실이 없다.
CoW 브랜칭: LSN 기반 타임라인
Neon 브랜칭은 O(1) 연산이다. 데이터베이스 크기와 무관하게 1초 이내에 완료된다.
브랜치 생성의 실제 동작
브랜치를 생성할 때 Neon이 하는 일은 현재 LSN 값을 기록하는 메타데이터 포인터를 만드는 것뿐이다. 어떤 데이터 파일도 복사되지 않는다.
브랜치 생성 이후:
- 브랜치에서 발생하는 쓰기는 브랜치만의 WAL 스트림을 만들고, 수정된 페이지만 브랜치의 레이어 파일에 기록된다.
- 수정되지 않은 페이지를 읽으면 Pageserver는 분기 시점 이전의 메인 타임라인 레이어 파일에서 페이지를 가져온다.
이것이 Copy-on-Write(CoW)다. 읽기는 공유하고, 쓰기만 분기한다.
브랜칭의 실용적 활용
스키마 변경 검증: 프로덕션 데이터 전체를 가진 브랜치를 1초 만에 만들어 DDL 변경을 테스트한다. 스테이징 환경에서 프로덕션 데이터로 마이그레이션을 리허설하는 비용이 거의 없다.
AI 에이전트 격리: 에이전트마다 독립된 데이터베이스 인스턴스가 필요할 때, 프로덕션 브랜치를 기반으로 수백 개의 브랜치를 생성할 수 있다. Databricks 인수 발표에서 "80%의 데이터베이스가 AI 에이전트에 의해 생성됐다"는 통계의 배경이다.
PITR(Point-In-Time Recovery): WAL이 전체 이력을 보관하므로 과거 임의의 LSN 시점으로 브랜치를 만들 수 있다. 데이터 복구가 브랜치 생성으로 간단해진다.
Scale-to-Zero: 컴퓨트만 끄면 된다
전통적인 PostgreSQL을 idle 시간에 종료하면 다시 시작할 때 파일시스템의 데이터 파일이 있어야 하고, shared_buffers를 다시 워밍업해야 한다.
Neon 컴퓨트는 무상태이므로 단순히 Postgres 프로세스를 종료한다. 재시작 시:
- Neon control plane이 컴퓨트 인스턴스를 새로 시작한다.
- Postgres 프로세스가 올라오면서 Pageserver에 접속한다.
- 첫 번째 페이지 요청부터 Pageserver가 서비스한다.
shared_buffers워밍업 없이 즉시 읽기·쓰기 가능하다.
Cold start는 Neon에서 측정된 수치 기준 500ms 이내다.
유휴 비용은 0이다. 컴퓨트 인스턴스 비용은 실제 실행된 시간에만 과금된다. 스토리지는 기간에 따라 별도 과금된다.
운영자 관점의 트레이드오프
장점
| 항목 | 내용 |
|---|---|
| Scale-to-zero | 유휴 인스턴스 비용 없음 |
| 브랜칭 | O(1), 데이터 크기 무관 |
| HA | Safekeeper 쿼럼 기반 내구성 |
| PITR | 모든 시점으로 브랜치 생성 가능 |
| 계산 분리 | 컴퓨트 재시작이 데이터에 영향 없음 |
제약과 주의사항
네트워크 레이턴시: 데이터 페이지 읽기가 네트워크 RPC를 경유한다. 로컬 SSD I/O와 비교하면 레이턴시가 높다. Pageserver 캐시에서 히트하면 빠르지만, cold read는 S3에서 레이어 파일을 읽어야 한다. I/O 집약적인 배치 쿼리는 성능에 영향을 받을 수 있다.
pgbouncer와의 상호작용: Scale-to-zero 중 들어온 연결을 처리하는 방법을 설계해야 한다. Neon은 연결 풀링과 cold start를 연계하는 프록시를 제공하지만, 애플리케이션 레벨에서도 재시도 로직이 있어야 한다.
PostgreSQL 확장 기능: Neon 컴퓨트는 일부 확장 기능을 지원하지 않는다. pg_cron처럼 별도 프로세스를 요구하는 확장은 동작하지 않을 수 있다.
쓰기 처리량 상한: WAL이 네트워크를 통해 Safekeeper로 전송되기 때문에 쓰기 집약적인 워크로드는 네트워크 대역폭에 제약받는다. TPS가 매우 높은 OLTP 워크로드(수천 TPS)에는 전통적인 RDS/온프레미스가 더 적합할 수 있다.
Neon이 적합한 시나리오
| 적합 | 덜 적합 |
|---|---|
| 개발·스테이징 환경 | 극도로 쓰기 집약적 OLTP |
| AI 에이전트별 격리된 DB | 수천 TPS 이상 고처리량 쓰기 |
| 수백~수천 개 소규모 DB | 레이턴시가 µs 단위로 중요한 쿼리 |
| 스키마 변경 테스트 | pg_cron 등 별도 프로세스 확장 |
| PITR 기반 복구 | 네트워크가 불안정한 환경 |
도입 체크리스트
- [ ] 워크로드의 TPS와 I/O 패턴을 측정하고 Neon free tier 또는 스테이징 환경에서 실측한다.
- [ ] Cold start 레이턴시(500ms 기준)가 애플리케이션 SLA에 허용되는지 확인한다.
- [ ] 사용 중인 PostgreSQL 확장 기능의 Neon 지원 여부를 공식 문서에서 확인한다.
- [ ] Scale-to-zero 중 유입 연결에 대한 재시도/대기 로직을 애플리케이션에 추가한다.
- [ ] 브랜칭 워크플로우를 CI/CD 파이프라인에 통합해 마이그레이션 리허설을 자동화한다.
- [ ] 데이터 리전과 컴퓨트 리전이 일치하는지 확인한다(Safekeeper·Pageserver·컴퓨트 동일 리전 배치가 성능에 중요하다).
- [ ] Databricks 인수 이후 엔터프라이즈 플랜의 SOC 2 Type 2 및 HIPAA 지원 범위를 보안팀과 검토한다.
한 문장으로
Neon은 Postgres 컴퓨트를 무상태로 만들고 WAL을 Safekeeper 쿼럼으로, 데이터 페이지를 Pageserver가 구체화하는 구조를 통해 O(1) CoW 브랜칭과 완전한 scale-to-zero를 PostgreSQL 위에서 구현한 서버리스 데이터베이스다.
References
- Neon GitHub Repository (neondatabase/neon): https://github.com/neondatabase/neon
- Deep dive into Neon storage engine (Neon Blog): https://neon.com/blog/get-page-at-lsn
- Databricks Agrees to Acquire Neon (Databricks Press Release): https://www.databricks.com/company/newsroom/press-releases/databricks-agrees-acquire-neon-help-developers-deliver-ai-systems
- Databricks and Neon (Databricks Blog): https://www.databricks.com/blog/databricks-neon
- Neon Database Review: Serverless Postgres Branching 2026 (getautonoma.com): https://getautonoma.com/blog/neon-database
- Neon — Serverless PostgreSQL — ASDS Chapter 3 (Jack Vanlightly): https://jack-vanlightly.com/analyses/2023/11/15/neon-serverless-postgresql-asds-chapter-3
- Neon safekeeper-protocol.md (GitHub): https://github.com/neondatabase/neon/blob/main/docs/safekeeper-protocol.md
- Neon pageserver-storage.md (GitHub): https://github.com/neondatabase/neon/blob/main/docs/pageserver-storage.md