What Is Supabase?
Supabase is an open-source Firebase alternative built on PostgreSQL — providing a full backend platform with database, authentication, storage, real-time subscriptions, and serverless functions.
Supabase is an open-source backend platform built on PostgreSQL that gives an app a hosted database, authentication, file storage, real-time subscriptions, and serverless functions behind one set of client libraries. It is most often described as an open-source alternative to Firebase, but the data layer is a real SQL database rather than a NoSQL document store.
What Supabase actually is
Under the hood it is a managed Postgres instance with services wired around it. You write standard SQL — tables, foreign keys, indexes — and Supabase auto-generates a REST and GraphQL API directly from your schema, so you can query data from a client without maintaining a separate ORM layer.
The platform bundles five core services:
- Database — hosted Postgres with full SQL: joins, foreign keys, views, triggers, and Row-Level Security (RLS).
- Auth — email/password, magic links, phone OTP, and OAuth providers (Google, GitHub, Apple, and others). Each signed-in user maps to a row Postgres can read via
auth.uid(). - Realtime — clients subscribe to row-level inserts, updates, and deletes as they happen in the database.
- Storage — S3-compatible file storage with the same access-policy model as the database.
- Edge Functions — Deno-based serverless functions deployed to a global edge network for custom server-side logic and webhooks.
How it works
The piece that ties everything together is Row-Level Security. RLS policies live in Postgres and decide which rows a user can read or write based on their auth token. Because the rule is enforced at the database, it protects the auto-generated REST API, GraphQL, Realtime, and Storage at once — you don't re-implement access control in each layer.
Client libraries (supabase-js for web, plus Flutter, Python, and others) talk to these services over HTTPS. On a typed stack, Supabase generates TypeScript types from your live schema, so a query result is typed end to end from the database column to the React component.
When to use Supabase — and when not to
| Use Supabase when | Reconsider when |
|---|---|
| Data is relational (users, orders, bookings, tenants) | Data is deeply nested, schema-less documents |
| You want SQL, joins, and complex queries | A simple key-value or document store is enough |
| You need auth, storage, and an API without standing up infra | You already run a mature custom backend |
| You may need SQL-friendly compliance and reporting later | Your team has no SQL experience at all |
Supabase fits multi-tenant SaaS, dashboards, marketplaces, and booking apps especially well, because those are relational by nature. The trade-off versus a NoSQL tool like Firestore is that you design a schema up front; the payoff is never flattening relational data into documents or fighting aggregation queries later.
Common mistakes
- Shipping with RLS off. A new table is readable by anyone with the public anon key until you enable RLS and write policies. This is the single most frequent Supabase security gap.
- Treating the anon key as a secret. It is publishable and meant for the browser; security comes from RLS, not from hiding the key. The
service_rolekey, by contrast, bypasses RLS and must stay server-side only. - Skipping indexes. It is Postgres — slow queries usually mean a missing index, not a platform limit.
A concrete example
A booking app stores a reservations table. An RLS policy auth.uid() = owner_id ensures each user reads only their own reservations. The web client subscribes to Realtime on that table, so a new booking appears live without a refresh, and an Edge Function handles the Stripe webhook and writes the paid status back — a full booking backend with no servers to manage. That is the same shape of backend behind production work like Pizzeria Bestek, which runs React on Supabase.
Key takeaways
- Is Supabase just a database? No — it is a backend platform: database plus auth, storage, realtime, and serverless functions.
- Is it really open source? Yes; you can self-host the stack, which avoids hard vendor lock-in.
- Free to start? It has a free tier suitable for validating an MVP, with usage-based pricing as you grow. For a build estimate, contact for a quote.
- Postgres under the hood means you scale into complex queries and reporting instead of outgrowing the tool.