Skip to content
Glossary

What Is Supabase?

Supabase is an open-source Firebase alternative built on Postgres — it provides a database, authentication, storage, real-time subscriptions, and Edge Functions from one platform.

Supabase is an open-source backend platform built on PostgreSQL that bundles a relational database, authentication, file storage, real-time subscriptions, and serverless Edge Functions behind a single API. It is the most common open-source alternative to Firebase, with the key difference that your data lives in plain Postgres rather than a proprietary NoSQL store.

What Supabase actually gives you

When you create a Supabase project you get a real Postgres database plus a layer of services that wrap it, so you can ship a working backend without standing up servers or writing CRUD endpoints by hand:

  • Postgres database — full SQL: joins, foreign keys, views, triggers, transactions, the complete relational model. You can connect with any Postgres client, not just Supabase's SDK.
  • Row-Level Security (RLS) — access rules enforced inside Postgres itself, so a user can only read or write rows that policies allow. This is the security backbone; the client SDK is not trusted on its own.
  • Auth — email/password, magic links, phone OTP, and OAuth providers (Google, GitHub, Apple, etc.). Auth issues a JWT that RLS policies read to decide access.
  • Realtime — subscribe to inserts, updates, and deletes on a table and receive them live in the client over websockets.
  • Storage — file uploads (images, documents, video) governed by the same policy model as the database.
  • Edge Functions — serverless TypeScript/Deno functions for logic that must not run on the client, such as calling a payment API or a secret-key service.
  • Auto-generated APIs — a REST interface (PostgREST) and an optional GraphQL endpoint are generated from your schema automatically.

How it works

Everything is anchored to Postgres. You define tables and relationships in SQL, and the REST/realtime layers are derived from that schema. The browser or mobile client talks to Supabase with a public anon key, and RLS policies — not the client — decide what each request is allowed to do. The user's JWT carries their identity into the database, so a policy like "a user can only select rows where user_id = auth.uid()" is enforced at the data layer. Anything requiring a secret (Stripe keys, third-party admin APIs) runs in an Edge Function or a server with the service-role key, which bypasses RLS and must never reach the browser.

Supabase vs Firebase

SupabaseFirebase
DatabasePostgres (relational, SQL)Firestore (NoSQL documents)
QueryingSQL: joins, aggregates, viewsPer-document; joins are awkward
Access controlRow-Level Security policiesSecurity Rules
Source modelOpen-source, self-hostableProprietary, Google-hosted
Best fitRelational data, multi-tenant SaaS, reportingSimple document apps, deep Google ecosystem use

The short version: pick Supabase when your data has real relationships or you want SQL and the option to self-host; pick Firebase when documents fit cleanly and you are committed to Google's stack.

When to use it — and when not to

Good fit: SaaS MVPs, multi-tenant apps, dashboards, anything with relational data, reporting, or a team that already knows SQL. The hobby tier covers a production-grade Postgres plus auth and realtime at no cost, so you skip DevOps entirely early on.

Think twice: if you need niche Postgres extensions or fine-grained instance tuning the managed tier doesn't expose (self-hosting is the escape hatch), or if your team is far more comfortable in Firestore and the app is genuinely document-shaped. Heavy compute or long-running jobs also belong on a dedicated server rather than Edge Functions.

Common mistakes

  • Shipping tables with RLS off. Disabled RLS plus the public anon key means anyone can read or write the whole table. Enable RLS and write explicit policies before launch.
  • Putting the service-role key in client code. It bypasses every policy. It belongs only in Edge Functions or a server.
  • Treating it like pure Firebase. Supabase rewards modeling your schema with proper foreign keys and constraints up front instead of denormalizing everything.

Example in production

Pizzeria Bestek pairs a React frontend with Supabase as the backend — Postgres holds the menu and orders, RLS guards access, and the app talks to it directly without a custom server. On this portfolio, Supabase also backs part of the AI chat API.

Key takeaways

  • Supabase = Postgres + auth + storage + realtime + Edge Functions in one platform.
  • Security lives in Row-Level Security, not in the client.
  • Choose it over Firebase when you want relational data, SQL, and the freedom to self-host.

Want a Supabase backend wired into your React or Flutter app? Contact for a quote.

Continue reading

Want this built?