Part VI. 운영, 비용, 한계

Branch를 1초에 만들 수 있다는 사실은 도입 근거의 절반입니다. 나머지 절반은 한 달 뒤 그 branch의 청구액에 달려 있습니다. 읽기 지연이 vanilla PostgreSQL과 어떻게 다른지도 중요합니다. 장애가 나면 어느 계층이 데이터를 지키는지도 확인해야 합니다. 아예 동작하지 않는 기능도 살펴봐야 합니다. 이 Part는 Neon을 운영 관점에서 평가할 때 필요한 숫자와 제약을 모아 정리합니다.

앞의 Part에서 "어떻게 동작하는가"를 다뤘다면 여기서는 "그래서 무엇을 감수해야 하는가"를 다룹니다. 수치는 2026년 9월 기준 공식 문서에서 가져왔습니다. 문서에 명시되지 않은 항목은 조건부 표현으로 남겼습니다.

• 6.1 비용 모델: CU-hour, GB-month, history 보존, child branch의 delta 과금
• 6.2 성능 특성과 Tail Latency: 읽기 경로 계층, prefetch, backpressure, 벤치마크 방법론
• 6.3 내구성과 가용성 모델: quorum commit, 장애 유형별 영향, HA 현황
• 6.4 호환성과 제약 목록: 버전, 확장, 연결 수, superuser, WAL 포맷
• 6.5 관리형 PostgreSQL 관점의 시사점: CoW를 어느 계층에 두는가

이 Part를 읽는 순서

비용 결정권이 있는 독자는 6.1과 6.4를 먼저 읽습니다. 성능 검증을 맡은 독자는 6.2의 벤치마크 방법론부터 시작합니다. 그런 다음 Part III의 실습 환경에서 재현합니다. 관리형 서비스를 설계하거나 도입을 검토하는 독자는 6.5를 먼저 읽습니다. 그런 다음 필요한 장으로 돌아옵니다.

전제

• 가격과 한도는 다음 문서를 기준으로 합니다. Neon Pricing, Neon Plans, Usage metrics입니다. 청구서에 반영되는 값은 콘솔의 Billing 페이지가 정본입니다.
• 자체 호스팅 구성(Part III)에는 control plane과 storage controller가 없습니다. 따라서 이 Part의 가용성 보장은 Neon 클라우드에만 해당합니다.
• Databricks Lakebase는 같은 저장 엔진을 쓰지만 HA/DR 기능 구성이 다릅니다. 따라서 별도 문서를 확인합니다.