Supabase overview

Introduction

Supabase is an open-source Backend-as-a-Service (BaaS) built on PostgreSQL. This post introduces what Supabase is, its main components (database, auth, API, storage, Realtime), its place in a modern backend stack, and when to choose it over self-hosted Postgres or other BaaS.

Goal: After this post you will have a high-level picture of the architecture, know which use cases fit Supabase, and be ready for the next posts (setup, schema, auth, API, deploy).

Features

What is Supabase

Supabase provides:

• Managed PostgreSQL: Postgres on the cloud with connection pooling (PgBouncer), backup, point-in-time recovery.
• Auth: Sign up / sign in (email, OAuth, magic link), JWT, session, refresh token.
• Auto API (PostgREST): REST API generated from your Postgres schema — CRUD by table/view, filter, pagination.
• Storage: File storage (S3-compatible), with policies tied to Auth.
• Realtime: Subscribe to table changes (postgres changes) over WebSocket.
• Edge Functions: Serverless functions (Deno) at the edge, with access to Auth and DB.

All of this has a dashboard (Studio), CLI, and consistent API; you can self-host or use Supabase cloud.

What to use it for

• Web/mobile apps that need a fast backend: auth, DB, API, files, realtime in one place.
• Prototype / MVP: Shorten the path from idea to something running.
• Small teams: One unified stack, fewer services to operate (DB, auth server, API server separately).

When to choose Supabase

• You need Postgres + auth + API quickly and don’t want to deploy many pieces yourself.
• You prefer open-source and the option to self-host or avoid lock-in.
• Most of your logic is CRUD + auth; for more complexity you can add a separate backend (NestJS, FastAPI) that talks to Supabase DB or PostgREST.

When not to choose: you need a different DB engine (MySQL, MongoDB), or heavy logic lives entirely in stored procedures/DB and needs tight hardware control.

Workflow / process

There is no single “one workflow”; a typical order is:

1. Create a project on Supabase (cloud or self-host) → get URL, anon key, service role key.
2. Design schema (tables, RLS) → write migrations.
3. Enable Auth (providers, redirect URL) → integrate in frontend/backend.
4. Call API from client (PostgREST) or from backend (service role when you need to bypass RLS).
5. Deploy migrations via CLI/CI; separate dev/staging/prod projects.

Apply early: separate environments (one project per env or clear branches), don’t commit secrets (env vars only), schema as source of truth (versioned migrations).

Sample code

Client connection (JavaScript)

import { createClient } from '@supabase/supabase-js';
 
const supabaseUrl = process.env.NEXT_PUBLIC_SUPABASE_URL;
const supabaseAnonKey = process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY;
 
const supabase = createClient(supabaseUrl, supabaseAnonKey);
 
// Query public table (RLS covered in post 7)
const { data, error } = await supabase.from('conversations').select('*').limit(10);

Call PostgREST from any HTTP client

curl -X GET "https://<project-ref>.supabase.co/rest/v1/conversations?select=*&limit=5" \
  -H "apikey: <anon-key>" \
  -H "Authorization: Bearer <jwt>"

URL and key from project settings; JWT is the token after Auth login.

Apply in your architecture

• Domain separation: Database (Postgres), Auth and API (PostgREST) are clear “domains”; you extend by adding tables, RLS, or a separate backend calling Supabase — avoid putting all logic in one unbounded monolith.
• Managed service: Supabase acts as a “managed component” in the stack; choosing Supabase is choosing the boundary between “what BaaS handles” and “what your backend implements”.
• API contract: PostgREST derives the API from schema; for a stable contract, schema and RLS must be stable and versioned via migrations — one source of truth for both DB and API.

Summary

Supabase is a Postgres BaaS: database, auth, auto API, storage, Realtime, Edge Functions. It fits when you need a fast backend and prefer Postgres and open-source. The next posts cover: project setup and env, schema design, migrations, auth JWT, Prisma, RLS, API, Realtime/Edge, deploy and CI/CD.

Next: 02 — Project setup, CLI and env

Further reading: Supabase Docs — Introduction