Neon에서 옮기기

두 제품 모두 PostgreSQL을 줍니다. 차이는 그 아래에 있습니다. Neon은 스토리지와 컴퓨트를 분리하고 스토리지 계층에서 브랜치를 만듭니다. CapyDB는 전용 스토리지 위에서 평범한 PostgreSQL 프로세스를 돌리고 그 스토리지를 복제해 브랜치를 만듭니다. 체감되는 결과는 CapyDB 셀이 노트북의 Postgres처럼 동작한다는 것입니다. 실제로 그것이기 때문입니다.

스키마, 쿼리, 확장 기능, 마이그레이션은 그대로 옮겨집니다. 신경 쓸 부분은 연결 계층과 제공자 전용 드라이버에 맞춰 쓴 코드입니다.

• -브랜칭: 프리뷰 데이터베이스는 수명이 있는 복제본이며 풀 리퀘스트마다 하나씩
• -제로 스케일: 유휴 셀은 잠들고 다음 연결에 깨어납니다. 보통 0.25초 이내
• -서버리스·엣지 런타임용 풀링 엔드포인트와 나머지를 위한 직접 엔드포인트
• -야간 스냅숏이 아니라 지속적 아카이빙에서 오는 특정 시점 복원
• -이미 쓰고 있는 배포 대상에 맞는 플랫폼 연동

• -HTTP나 WebSocket 드라이버는 없습니다. 모든 드라이버가 이미 말하는 PostgreSQL 와이어 프로토콜로 연결합니다
• -격리는 프로젝트마다 프로세스 하나와 스토리지 하나이지, 공유 컴퓨트 계층 안의 테넌트가 아닙니다
• -컴퓨트는 요금제별 고정 CPU·메모리 상한이며 자동 확장 단위가 아닙니다
• -표준 셀에는 아웃바운드 네트워크가 없어, 외부를 호출하는 확장은 구조상 쓸 수 없습니다

프로젝트가 Neon 전용 서버리스 드라이버를 가져다 쓴다면 CLI가 대신 고쳐 씁니다. 코드모드는 클라이언트를 표준 PostgreSQL 드라이버로 바꾸고, 연결 설정을 정리하고, 판단이 필요한 호출부는 추측하지 않고 보고합니다.

# Dry run by default - nothing is written until you say so
capydb migrate codemod neon
capydb migrate codemod neon --write

기존 연결 문자열을 대상으로 가져오기를 시작하세요. 팔로우 모드가 테스트하는 동안 새 셀을 원본과 동기화해 주므로, 전환은 유지보수 시간이 아니라 DNS와 환경 변수 변경으로 끝납니다.

capydb import \
  --project my-app \
  --source-url "$OLD_DATABASE_URL" \
  --follow

• -팔로우로 가져오기를 켜 둔 채 테스트 스위트를 셀에 대해 돌립니다
• -capydb doctor로 아직 옛 데이터베이스를 가리키는 환경 변수를 잡습니다
• -배포 플랫폼에서 연결 문자열을 교체합니다. 연동 기능이 환경별로 처리해 줍니다
• -처음 몇 분은 대시보드에서 로그와 연결 수를 지켜봅니다
• -만족스러우면 팔로우를 멈추고 원본을 정리합니다

프로덕션 전환은 시작 전에 알려주세요. 계획을 검토하고, 그 시간대에 대기하며, 복구 경로를 준비해 둡니다. 비용은 없고, 지루한 저녁과 흥미진진한 저녁의 차이를 만듭니다.