Supabase를 떠날 시점 판단하기
제어 한계와 운영 역량이 BaaS의 속도 이점을 넘어설 때만 이전한다
정의
이탈 결정은 성장한 워크로드에 이제 필요한 제어권과 팀이 데이터베이스를 운영하고 주변 백엔드 서비스를 대체할 수 있는 역량을 비교한다.
관점
Bear_DBA (@bear_dba) (2026-08-28, Threads)
빠른 CRUD, 인증, 스토리지, realtime 기능이 인프라 제어권보다 더 가치 있는 동안에는 Supabase로 시작하라. 조정할 수 없는 느린 쿼리, 고갈된 connection pool, 관리하기 어려운 RLS 정책 10개 초과, PL/pgSQL에 쌓이는 핵심 비즈니스 로직, 월 $200 초과 비용, multi-region 또는 자동 failover 요구, 지원되지 않는 extension, 인프라 관련 규제, 데이터베이스를 운영할 수 있는 사람 가운데 최소 세 가지 신호가 반복되면 본격적인 이전 검토를 시작하라.
팀이 5명 이하이고 전담 백엔드 담당자가 없거나, 트래픽이 예측 가능하거나, 데이터가 10GB 미만이거나, 인프라 경험 또는 product-market fit이 없으면 남아라. 결정적인 질문은 서비스에 더 많은 제어권이 필요한지와 팀이 그 제어권을 행사할 수 있는지다. 두 답이 모두 yes일 때만 이전하라.
적용
- 아직 product-market fit을 찾는 제품이 아니라 빠른 B2C 앱 MVP의 속도 우선 가정을 이미 벗어난 제품에 맞는다.
- 반복되는 운영 장애와 팀 역량을 공동 관문으로 다룬다. 가격 기준만 보면 소유에 따르는 노동 비용을 놓친다.
- 이탈 조건을 충족했다면 백엔드 전체를 한꺼번에 바꾸지 말고 Supabase 데이터베이스 이전을 단계적으로 진행하기로 이어간다.
- 애플리케이션의 쿼리, 트랜잭션, 이식성 요구가 명확해진 뒤에만 데이터베이스 우선 경로와 Firebase를 비교한다.
- 데이터베이스를 넘어서는 더 넓은 build-versus-buy 감사는 고비용 SaaS를 자체 서비스로 대체하기로 이어간다.
한계
- 플랜 한도, 가격, 인스턴스 크기, 기능 제공 여부, extension 지원은 한 저자의 스냅샷이며 현재 Supabase 문서와 대조하지 않았다.
- 신호 세 가지, RLS 정책 10개, 월 $200, 5명, 10GB 기준은 측정된 손익분기점이 아니라 휴리스틱이다.
- Threads 글에서 "Self-managed"는 RDS, Cloud SQL 같은 관리형 PostgreSQL 목적지도 포함하므로 bare infrastructure에서 PostgreSQL을 운영한다는 뜻은 아니다.