Neon 데이터베이스 브랜칭이 월 200 유로를 절약하게 해줬습니다

저는 프로젝트당 14 개의 Neon 데이터베이스 브랜치를 하나의 Postgres 인스턴스 가격에 운영합니다. Neon 의 복사-온-라이팅(copy-on-write) 브랜칭 기술은 12 GB 크기의 데이터베이스를 1 초 미만으로 복제합니다. GitHub Action 은 풀 리퀘스트마다 새로운 브랜치를 시작하고 병합 시 이를 종료시킵니다. Postgres 비용이 월 240 유원에서 Neon 으로 전환한 후 월 40 유원으로 떨어졌습니다.

저는 과거에 프로젝트마다 개발용 DB, 스테이지용 DB, 프로덕션용 DB 가 각각 필요했고, 총 4 개의 프로젝트를 운영했기 때문에 매월 240 유원을 지불했습니다. 이후 Neon 으로 전환하여 14 개의 환경을 그대로 유지하면서 비용은 40 유원으로 줄었습니다. 이 계산이 어떻게 이루어지는지 자세히 설명하겠습니다.

왜 14 개의 데이터베이스 환경이 있었는지
개인 개발자, 네 가지 제품, 그리고 저 혼자입니다. 비용이 빠르게 불어나기 쉽습니다. 각 제품은 최소 세 개의 Postgres 환경이 필요합니다. 로컬 (Local), GitHub 미리보기 배포용 스테이지 (Staging), 고객용 프로덕션 (Prod) 입니다. 이는 총 12 개입니다. 여기에 Studio 백엔드를 위한 콘텐츠 마이그레이션과 실험적 스키마를 유지하는 두 개의 장기 기능 브랜치를 더하면 총 14 개가 됩니다.

구형 설정에서는 각 환경당 Supabase 인스턴스를 하나씩 사용했습니다. 가장 작은 유료 티어 기준으로도 약 월 25 유원 정도였습니다. 무료 티어를 사용할 수 없었던 이유는 비활성화 후 일주일 만에 자동 정지 (auto-pauses) 되기 때문이었습니다. 일요일 밤 9 시에 개발용 DB 가 정지되는 것은 가장 고통스러운 경험 중 하나입니다. 따라서 14 개의 인스턴스 × 평균 약 17 유원 = 총 약 240 유원이 되었습니다.

가장 고통스러웠던 점은 이 14 개 데이터베이스 중 13 개는 95% 의 시간을 비활성 상태로 보냈다는 것입니다. 개발용 DB 는 하루에 두 번만, 스테이지는 주에 네 번 정도만 수정했고, 프로덕션은 혼자 돌아가기만 했습니다. 즉, 항상 켜져 있는 컴퓨팅 자원을 1.5 개 분의 용량만 사용하고 있었습니다.

또 다른 두 가지 불편함으로 인해 다른 대안을 찾기 시작했습니다. 첫째, 로컬에서 파괴적 마이그레이션 (destructive migration) 을 테스트할 때마다 prod 를 pg_dump 하고 dev 에 복원한 뒤 스키마가 맞는지 기도를 해야 했습니다. 이 과정은 테스트당 20 분이 걸렸습니다. 둘째, Shopify 백엔드 프로젝트의 풀 리퀘스트를 열었을 때 미리보기 배포가 스테이지를 가리켰기 때문에 두 개의 병행 중인 PR 이 서로 충돌할 수 있었습니다.

저는 제가 눈치채지 못했던 것은 위험한 작업을 피하는 빈도였습니다. 깨끗한 복사본에서 파괴적 마이그레이션을 실행하는 데 20 분이 걸리면 주에 두 번만 시도합니다. 하지만 1 초면 하루에 열두 번 시도할 수 있습니다. 이는 마이그레이션 작성 방식을 바꾸게 됩니다. 저는 이제 비용이 사실상 제로에 가깝기 때문에 더 작고 되돌릴 수 있는 마이그레이션을 작성하기 시작했습니다.

Neon 브랜칭이 실제로 어떻게 작동하는지
Neon 은 Postgres 를 스토리지 (storage) 와 컴퓨트 (compute) 로 분리합니다. 스토리지는 공유되고 콘텐츠 주소화 가능한 레이어이며, 컴퓨트는 해당 스토리지를 읽고 쓰는 일반적인 Postgres 인스턴스입니다. 브랜치는 단순한 포인터일 뿐입니다. main 에서 브랜치를 생성할 때 Neon 은 데이터를 복사하지 않습니다. 대신 현재 LSN (log sequence number) 를 표시하고, 브랜치상의 새로운 쓰기는 새 페이지로 가고, 변경되지 않은 부분의 읽기는 부모의 페이지로 전달됩니다. 이는 복사-온-라이팅 (copy-on-write) 방식과 동일한 원리입니다.