Deciding When to Leave Supabase

Definition

An exit decision compares the control a growing workload now requires with the team's ability to operate a database and replace the surrounding backend services.

Perspectives

Bear_DBA (@bear_dba) (2026-08-28, Threads)

Start on Supabase while fast CRUD, authentication, storage and realtime features are worth more than infrastructure control. Begin serious migration review when at least three signals recur: untunable slow queries, exhausted connection pools, more than ten unmanageable RLS policies, core business logic accumulating in PL/pgSQL, monthly cost above $200, multi-region or automatic failover requirements, an unsupported extension, infrastructure-specific regulation, or a person capable of operating the database.

Stay when the team has five or fewer people and no dedicated backend owner, predictable traffic, less than 10GB of data, no infrastructure experience or no product-market fit. The decisive questions are whether the service needs more control and whether the team can exercise it; migrate only when both answers are yes.

How to apply

• Fits a product that has already outgrown the speed-first assumptions behind Rapid B2C App MVP, not one still searching for product-market fit.
• Treat recurring operational failure and team capability as joint gates; a price threshold alone ignores the labor cost of ownership.
• If the exit gate is met, continue with Staging a Supabase Database Migration rather than replacing the whole backend at once.
• Compare the database-first path with Firebase only after the application's query, transaction and portability requirements are explicit.
• For the broader build-versus-buy audit beyond databases, continue with Replacing High-Cost SaaS with Owned Services.

Limits

• Plan limits, prices, instance sizes, feature availability and extension support are a single author's snapshot and were not checked against current Supabase documentation.
• The thresholds of three signals, ten RLS policies, $200 per month, five people and 10GB are heuristics, not measured break-even points.
• "Self-managed" in the thread includes managed PostgreSQL destinations such as RDS and Cloud SQL, so it does not necessarily mean operating PostgreSQL on bare infrastructure.

Original link