Supabase 데이터베이스 이전을 단계적으로 진행하기
API를 분리하고 PostgreSQL을 옮긴 뒤 부가 서비스를 단계적으로 교체한다
정의
단계적 BaaS 이전은 애플리케이션 접근, PostgreSQL 데이터, 부가 서비스를 분리해 한 번에 모두 전환하지 않고 각 경계를 변경하고 확인할 수 있게 한다.
관점
Bear_DBA (@bear_dba) (2026-08-28, Threads)
먼저 기존 Supabase 데이터베이스 앞에 백엔드 API를 두어 PostgREST를 직접 호출하지 않게 하라. 다음으로 pg_dump와 pg_restore를 사용해 PostgreSQL을 RDS, Cloud SQL 또는 다른 대상으로 옮기고 백엔드 connection string을 바꿔라. 데이터베이스 이전이 끝난 뒤에만 Auth, Storage, Realtime, Edge Functions를 교체하고, 처음 두 단계 사이에는 병렬 읽기와 쓰기로 전환 전 정합성을 확인하라.
auth.users, password-hash 호환성, storage.objects, 기반 object file, RLS 정책, pg_net·pg_cron 같은 Supabase 전용 설정을 목록화하라. 이전으로 RLS 동작이 사라지는 곳에서는 애플리케이션 계층에 권한 부여를 다시 구현하고, PostgreSQL의 이식성이 주변 서비스까지 포함한다고 가정하지 마라.
적용
- Supabase를 떠날 시점 판단하기에서 제어권 필요와 백업, 모니터링, 패치, 인시던트를 책임질 운영자를 모두 확인한 뒤에만 시작한다.
- 데이터베이스를 옮기는 동안 API 경계를 안정적으로 유지한다. 그러면 클라이언트, 데이터, 인증의 동시 변경이 줄어든다.
- 임시 병렬 쓰기가 영구적인 복잡성이 되지 않도록 이중 운영 전에 정합성 검사, 롤백 조건, 종료일을 정한다.
- 제품이 여전히 속도 우선 MVP 단계라면 이전 부담과 Firebase 또는 Supabase에 남는 선택을 비교한다.
한계
- Threads 글은 순서만 제시하며 테스트된 명령어, 다운타임 추정치, 롤백 절차, 스키마별 이전 runbook은 제공하지 않는다.
- 이중 쓰기는 출처에서 해결 방법을 설명하지 않은 정합성 실패 모드를 만들 수 있다.
- RDS, Cloud SQL, Auth0, Clerk, S3, CloudFront는 대표 URL이나 출처 기반 비교 없이 목적지로만 언급돼 별도 도구 페이지를 만들지 않았다.