Supabase

Supabase is a Backend-as-a-Service built on PostgreSQL rather than a proprietary database. You get Firebase-style convenience — auth, storage, realtime, instant APIs — with the power, SQL, and portability of Postgres, and no lock-in.

Every project is a full Postgres database with Authentication, file storage, realtime subscriptions, and edge functions, reachable via auto-generated REST/GraphQL APIs or official client libraries. The thing to internalize first is Row Level Security — in Supabase, the database enforces who can see what.

TL;DR

• It's real Postgres with batteries included — you're not locked in.
• Row Level Security (RLS) is the primary security model.
• The anon key is safe to expose; the service_role key is a superuser — never ship it to clients.
• Treat your schema and policies as code (migrations in version control).

Quick Example

The client talks straight to Postgres; RLS policies decide what comes back — no manual filtering:

Core Concepts

• PostgreSQL — unmodified Postgres: SQL, constraints, indexes, triggers, extensions (pgvector, PostGIS).
• Auth (GoTrue) — email/password, magic links, OAuth, phone OTP, anonymous sign-in.
• Storage — S3-compatible files with RLS policies and image transforms.
• Realtime — subscribe to database changes over websockets.
• Edge Functions — Deno/TypeScript serverless functions for webhooks and custom endpoints.

Row Level Security

RLS moves authorization into the database. With it enabled, every query behaves as if a WHERE clause from your policies is appended — and policies can read auth.uid():

⚠️ A table without RLS enabled is fully readable by anyone with the anon key. Enable RLS on every user-facing table, then add policies.

The Two API Keys

The service_role key is effectively a database superuser; if it leaks, an attacker has full access.

Best Practices

• Deny by default — enable RLS before adding policies, and test as real users, not the superuser.
• Migrations as code — keep supabase/migrations/*.sql in version control; deploy via supabase db push or CI.
• Generate types from your schema (supabase gen types typescript) for end-to-end type safety.
• Review RLS policies in code review — they're as important as application code.

Common Mistakes

Forgetting to enable RLS

Shipping the service_role key to the client

FAQ

What is Supabase, exactly?

A suite of tools around a real Postgres database: authentication, storage, realtime, auto-generated APIs, and edge functions. It's positioned as an open-source Firebase alternative, but because it's Postgres underneath, you keep full SQL and can leave without rewriting your data layer.

What's the difference between the anon and service_role keys?

The anon key is public and fully governed by your RLS policies — safe in client code. The service_role key bypasses RLS and acts as a superuser, so it must stay on the server. Treat it like a database password.

How does Row Level Security work?

You enable RLS on a table and write policies that act like automatic WHERE/WITH CHECK clauses. Each request runs with the user's JWT, so policies can reference auth.uid() to scope access per user, team, or role — enforced by the database, not your app code.

When should I choose Supabase?

For startups, MVPs, and apps that want auth + database + storage + realtime as one package with Postgres underneath, without running infrastructure. Consider alternatives if you need fine-grained infra control, a different auth provider, or a non-relational data model.

Related Topics

• PostgreSQL — The database underneath
• Authentication — Auth strategies (GoTrue)
• Neon — Another serverless Postgres platform
• API Security — RLS as defense in depth
• Backend Development — Where Supabase fits

References

• Supabase — Documentation
• Supabase — Row Level Security
• Supabase — Local development & CLI
• PostgREST