Supabase

What it is

Supabase is an open-source backend-as-a-service that bundles managed Postgres with auth, realtime subscriptions, file storage, vector search, and edge functions. The pitch is “Firebase, but open source and on top of a real relational database.”

It’s not a single product but a curated stack: Postgres for data, an internal auth service for identity, PostgREST for the auto-generated REST API, Realtime (Elixir) for change streams, Storage for files, and Deno-based edge functions. Each piece is open source, and the whole stack is self-hostable via Docker Compose.

Founded in 2020 by Paul Copplestone and Ant Wilson.

Why people use it

• Postgres is the source of truth. Unlike Firebase or DynamoDB, your data is in a real relational database with SQL, transactions, joins, and the entire Postgres ecosystem.
• Auto-generated APIs. PostgREST exposes your tables as a REST API based on the database schema. Row-level security (RLS) policies enforce authorization at the database layer.
• Realtime subscriptions. Postgres logical replication is converted to WebSocket events. Clients can subscribe to row changes without you writing a pub/sub layer.
• Auth. Email/password, OAuth providers, magic links, and JWT issuance — all wired into RLS so policies can reference auth.uid().
• Self-hostable. The entire stack runs in Docker. Many startups prototype on Supabase Cloud and migrate to self-hosting later for cost or control reasons.

When to use Supabase

• Full-stack apps where you want auth + database + realtime + storage from one provider.
• Rapid prototyping. The “create project” to “first query” time is under five minutes.
• Apps where RLS-based authorization fits (per-row ownership patterns).
• Teams that want the option to leave the managed product without rewriting — self-hosting is a real escape hatch.

When not to use Supabase

• You only need Postgres. If you don’t need auth/realtime/storage, plain RDS, Neon, or Supabase-as-Postgres-only is overkill. Pick a focused product.
• You need custom auth flows. Supabase auth is good for common patterns but constrains you. If you need complex multi-factor flows, federated identity, or fine-grained organization/tenancy auth, you’ll fight the framework.
• Heavy write workloads at scale. Realtime and PostgREST add overhead per request. At very high write throughput, you may bypass them and hit Postgres directly anyway.
• You want Firebase’s offline-first sync. Supabase Realtime is server-to-client change streams, not bidirectional offline-capable sync.

Notable trade-offs

• RLS is powerful but easy to misconfigure. A wrong policy exposes data. Test policies the way you’d test access control code — with adversarial cases.
• Auto-generated REST API can leak schema details. Anything reachable through PostgREST is exposed by default unless you explicitly hide it. Schema design matters more than usual.
• Realtime has scaling limits. Each WebSocket connection holds resources. At thousands of concurrent subscriptions, you’ll need to think about sharding or paid tiers.
• The stack is the lock-in. Each piece is open source, but the integration between them is what you actually use. Self-hosting works but is operationally non-trivial.

Managed offering

Supabase Cloud is the primary managed product. Free tier includes 500 MB storage, 50K monthly active users, and unlimited API requests. Self-hosting on Kubernetes via the Helm chart is supported but requires real ops investment.