Understand the Supabase platform

Supabase is PostgreSQL with the services around it already set up. Not a compatible clone, not a proprietary store hidden behind an API. Every project you create is a real Postgres database, and you can reach it with any Postgres client.

You can prove that in one command:

psql "postgresql://postgres:s3cretPass@db.abcdefghijkl.supabase.co:5432/postgres" \
  -c "select version();"
# PostgreSQL 15.8 on aarch64-unknown-linux-gnu ...

That’s plain psql talking to your project the same way it talks to a database on your laptop.

Around that database, Supabase adds the pieces most apps need anyway: a generated data API, authentication, file storage, realtime, functions, connection pooling, backups, and a dashboard. Each one is a service you don’t have to run yourself.

How a request flows

The piece that confuses people the most is the Data API, an HTTP layer that turns requests into SQL. When you write this in the browser:

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

const supabase = createClient(
  'https://abcdefghijkl.supabase.co',
  'sb_publishable_x3PLxbGmiQ04GJ5uOOZBww_T5xRcLhV'
)

const { data, error } = await supabase.from('notes').select()

no server of yours is involved. The request hits the Supabase API gateway, which translates it into SQL and runs it against your Postgres database.

Two layers do two different jobs along the way. Supabase Auth authenticates: it checks the user’s token and attaches their identity to the request. PostgreSQL authorizes: Row Level Security policies decide which rows that identity may see.

My advice is to draw that path once on paper. Browser, Auth, Data API, Postgres. Then mark the two jobs. Authentication happens before the database. Authorization happens inside it. Keep that picture in mind and most of the platform makes sense.

It is still Postgres

SQL, constraints, indexes, transactions, roles, and query plans still matter. The platform removes setup work. It does not remove database design, and it does not make authorization decisions for you.

The classic first-week surprise makes the point. You enable Row Level Security on a table, you write no policies, and every select starts returning an empty array:

const { data, error } = await supabase.from('notes').select()
console.log(data, error)
// [] null

No error. Just data: []. Nothing is broken and nothing is lost. Postgres is doing exactly what you told it: no policy allows any rows, so no rows come back. The fix is a policy, and writing one is a database skill, not a platform setting. We’ll write those policies later in this course.

Treat Supabase as Postgres with the boring parts handled. Everything you already know about relational databases keeps paying off here.