When You Should NOT Use Supabase

Most Supabase content - including a lot of what's on this blog - is about how well it works. That's true for a large share of projects, but treating it as the default answer for everything leads to real problems in a specific set of cases. This is the honest list of when to reach for something else.

Heavy offline-first mobile apps

Supabase's client libraries do not have mature offline persistence and conflict resolution comparable to Firestore's mobile SDKs. If the app needs to function fully - reads and writes - while disconnected, and reconcile cleanly when connectivity returns, you're fighting the tooling rather than being helped by it. This is the single clearest case where Firebase is still the better default, and it's not close.

Extremely high write-throughput, append-only workloads

Postgres is a general-purpose relational database, not a purpose-built time-series or event-ingestion store. If the core of the app is ingesting massive volumes of write-once, rarely-queried-relationally data - IoT telemetry at scale, high-frequency event logs, analytics pipelines processing millions of events per minute - a purpose-built store (ClickHouse, TimescaleDB, a managed event pipeline) will outperform Postgres-on-Supabase by a wide margin. You can run this on Supabase at moderate scale, but at real scale you'll end up re-architecting around a dedicated ingestion path anyway. Better to know that going in.

When you need multi-region active-active writes

Supabase's Postgres is fundamentally a single-primary database (with read replicas available on higher tiers). If the actual requirement is active-active writes across multiple regions with low latency everywhere - genuinely global user bases needing local write latency, not just read latency - you need a distributed database designed for that (CockroachDB, Spanner, etc.). Supabase can serve global read traffic well with replicas; it doesn't solve global write latency.

Simple apps with no relational structure at all

If the app's entire data model is "one JSON blob per user" - a config store, a simple key-value cache, a single-user note app with no sharing or relationships - bringing in a full Postgres instance with RLS policies and schema migrations is more infrastructure than the problem needs. A simpler key-value store, or even Firestore's document model, fits better and costs less mental overhead to maintain.

Teams with zero SQL experience and a very short timeline

This one is about people, not technology. Supabase rewards relational thinking - schema design, joins, RLS policies written as SQL. A team that has never worked with a relational database and needs to ship in two weeks will move faster on a platform closer to what they already know (Firestore, or a simpler BaaS), even if Supabase would be the technically better long-term choice. The migration cost of "wrong tool, right team" is usually lower than "right tool, team learning SQL under deadline pressure."

When your actual bottleneck is something Supabase doesn't solve

Sometimes the honest answer is that the backend platform was never the problem. If an app is slow because of unoptimized frontend rendering, a chatty API design, or missing caching - switching from Firebase to Supabase (or vice versa) won't fix it. Worth ruling this out before treating a platform migration as the fix.

The pattern behind all of these

Every case above shares the same shape: Supabase is excellent at being "Postgres with batteries included" - auth, storage, realtime, edge functions, all wired together. It is not excellent at being something structurally different from Postgres: an offline-first mobile datastore, a distributed multi-region write system, or a high-throughput event ingestion pipeline. Knowing which category your project actually falls into is the whole decision.

If you're not sure which category your project is in, or you're mid-build and starting to feel the platform pushing back against what you're trying to do, that's worth a second opinion before committing further - book a call and we can look at your specific requirements together.