What Is Supabase

The idea in one sentence

Supabase is an open-source Backend as a Service built around a real, unmodified Postgres database — you get an auto-generated API, auth, storage, and realtime for free, but the core is still plain Postgres you can query with plain SQL any time you want.

Postgres first, services second

If you built a backend from scratch, you would end up writing an authentication service, some kind of query API, a realtime layer for pushing live updates, and a file storage service — on top of whatever database you chose. Supabase’s pitch is that it gives you all of that already built, wired together, and running against a database you fully own and can query directly.

That last part is the important distinction from Firebase. Firebase’s Firestore is a proprietary, schemaless NoSQL document store — your data model and your queries are locked into Firebase’s specific API shape, and there is no SQL escape hatch. Supabase is the opposite bet: the database is standard Postgres, so:

You can connect with psql, any Postgres driver, or any ORM that speaks Postgres.
Your schema is relational tables, foreign keys, and constraints — not implicit document shapes.
If you ever need to leave Supabase, you can pg_dump your database and run it anywhere Postgres runs.

-- This is just Postgres. No proprietary query language, no vendor-specific data model.
select id, username, created_at
from public.profiles
where created_at > now() - interval '7 days'
order by created_at desc;

The core services at a glance

One Supabase project is one Postgres database plus a set of managed services layered around it. Each of these gets its own module later in this course, so keep this as an orientation map, not the deep dive:

Postgres database — the actual data store, plain SQL, full relational features.
Auto-generated API — a REST/RPC API via PostgREST, and a GraphQL API via pg_graphql, generated directly from your schema.
Auth (GoTrue) — user sign-up, sign-in, session management, and social/SSO providers.
Storage — an S3-compatible object store for files, with its own access policies.
Realtime — subscribe to database changes, or use ephemeral broadcast/presence channels, over WebSockets.
Edge Functions — custom server-side logic written in TypeScript, running on Deno at the edge.

All of it is configurable from the Supabase Studio dashboard (a web GUI) or from the Supabase CLI, which you will set up in the next lesson.

import { createClient } from '@supabase/supabase-js';

const supabase = createClient(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_ANON_KEY!
);

// Under the hood this is a PostgREST request against the profiles table.
const { data, error } = await supabase
  .from('profiles')
  .select('id, username, created_at')
  .order('created_at', { ascending: false });

flowchart TB
  pg[("Postgres database")]
  api["REST/RPC API (PostgREST) + GraphQL (pg_graphql)"]
  auth["Auth (GoTrue)"]
  storage["Storage"]
  realtime["Realtime"]
  functions["Edge Functions (Deno)"]
  api --> pg
  auth --> pg
  storage --> pg
  realtime --> pg
  functions --> pg

One Postgres database with services layered around it

Why not just roll your own?

Nothing here is magic you could not build yourself — PostgREST, GoTrue, and the rest are open-source projects you could self-host individually. What Supabase actually saves you is the integration work: one project, one set of credentials, one dashboard, and services that already know how to talk to each other and to the same Postgres instance. You still write the schema, the SQL, and the access rules — Supabase just removes the plumbing around them.