Why a glossary is worth reading
Supabase inherits vocabulary from four different worlds: Postgres, the PostgREST ecosystem, JWT-based auth, and modern edge compute. Reading a support thread or a docs page often means bouncing between all four vocabularies in a paragraph. This glossary defines the 25 terms you will meet in the first month, grouped by where they live in the platform. Each definition is short enough to skim and precise enough to trust; if a definition is followed by a rule of thumb, the rule is what the docs assume you already know.
Core platform
- Project — a single provisioned Postgres instance plus its API gateway, Auth server, Storage service, Realtime service, and Edge Functions runtime. Every project has one region and one URL of the form <ref>.supabase.co.
- Organization — the billing and team-membership container that owns one or more projects. Pro projects are billed per-project; Team and Enterprise pool quotas across an org.
- Publishable key — the anon key that is safe to ship in a browser bundle. It identifies the project and is gated by RLS on every request.
- Service role key — a secret key that bypasses RLS and grants full database access. Server-side only, never exposed to a client, never checked into git.
- Data API — the auto-generated REST endpoint (PostgREST) that exposes tables, views, and RPC functions over HTTPS. Every request is checked against RLS using the caller's JWT.
Auth
- GoTrue — the open-source Auth server that powers Supabase Auth. You interact with it through the SDK, not directly.
- MAU — Monthly Active User. Any user who signs in once in a calendar month counts once. The Auth billing metric on every tier.
- JWT — JSON Web Token. The signed access token GoTrue issues after login. Postgres RLS reads auth.uid() and auth.jwt() from it.
- OAuth provider — an external identity provider (Google, Apple, GitHub, Azure, and many more) wired through Supabase Auth so users can sign in without a password.
- Anonymous sign-in — a signed session for a user with no identity yet. Useful for guest carts and onboarding flows; still counts toward MAU.
- Magic link — an emailed one-time URL that signs the recipient in without a password. Cheap, low-friction, and increasingly the default flow for consumer apps.
Database and query layer
- RLS — Row Level Security. Postgres feature Supabase enforces on the Data API. Attaches a boolean expression to every SELECT, INSERT, UPDATE, DELETE.
- Policy — the SQL rule attached to a table by RLS, with USING for reads and WITH CHECK for writes.
- Publication — the logical-replication set of tables that Realtime subscribes to. Enabling realtime on a table adds it to a publication behind the scenes.
- Supavisor — Supabase's Postgres connection pooler, the replacement for the older PgBouncer setup. It multiplexes many client connections onto a small pool of backend connections and is what serverless functions should connect through.
- pgvector — the Postgres extension that adds a vector data type and similarity operators. The foundation of every RAG and semantic-search feature built on Supabase.
- PostgREST — the open-source project that turns a Postgres schema into a REST API. Supabase's Data API is a managed PostgREST deployment.
Storage and compute
- Storage — S3-compatible object storage, bucketed per project. Buckets can be public (world-readable) or private (RLS-gated per row of the storage.objects table).
- Smart CDN — Supabase's cached edge in front of public storage objects. Turning it on cuts egress cost and speeds up first-byte for images and downloads.
- Edge Function — a Deno function deployed to Supabase's global edge runtime. Isolate-per-request, cold starts in tens of ms, invoked over HTTPS with your JWT.
- Realtime — the WebSocket service that streams Postgres change events, presence, and broadcast messages to subscribed clients, honoring RLS on every event.
- Database webhook — a trigger-based hook that fires an HTTP request to an Edge Function or external URL when a row changes. The Supabase-native way to run side effects on writes.
Operations and reliability
- PITR — Point-In-Time Recovery. Restores the database to any second within the retention window. 7 days on Pro, 28 on Team, longer on Enterprise.
- Read replica — a follower Postgres instance for read-heavy workloads. Available on Team and above; queried through the same client with a replica-aware connection.
- Compute add-on — the per-project instance size (Micro, Small, Medium, Large, XL, XXL). The biggest lever on database performance under load.
- Region — the AWS region the project is pinned to at creation. Cannot be changed later; migrating regions means creating a new project and moving data.
Frontend and integration surface
A handful of terms show up when you wire a frontend to Supabase and are worth naming so they stop being magic. The supabase-js client is the JavaScript SDK that wraps the Data API, Auth, Storage, Realtime, and Functions behind one object created with createClient(url, key). The auth session is the in-memory (and optionally persisted) token pair that supabase-js manages for you, refreshed transparently before expiry. A row-level subscription is a Realtime channel you open with supabase.channel('...').on('postgres_changes', ...); it survives page reloads if you re-open it, but it is not a background service. A server client is a supabase-js instance created with the service role key inside a trusted server function, and it is the only place that key should ever live.
Working with the CLI and local dev
The Supabase CLI runs the entire platform locally in Docker for offline development: Postgres, GoTrue, PostgREST, Storage, Realtime, and Studio (the local dashboard). supabase start boots the stack, supabase db push applies migrations from your repo, supabase functions serve runs Edge Functions locally against the local database. Local dev is fully offline and free, which makes it the correct default for building features before you ever touch a hosted project. When you do deploy, the same migration files apply to staging and production in order, and the same client code points at the hosted URLs by swapping environment variables.
Common acronyms in the docs
A cluster of three-letter acronyms shows up on every Supabase page and is worth spelling out once. MFA is multi-factor authentication, offered through GoTrue with TOTP and (increasingly) WebAuthn factors. SSO is single sign-on, meaning your dashboard users authenticate through a SAML or OIDC identity provider instead of a Supabase-managed password. RPC in the Supabase SDK means calling a Postgres function you defined with CREATE FUNCTION, invoked as supabase.rpc('function_name', args). REST refers to the PostgREST-generated endpoints. WAL is the Write-Ahead Log Postgres uses to guarantee durability and to feed logical replication (which is what Realtime subscribes to).
Terms that appear in incident reports
When Supabase writes a status update the vocabulary narrows to a small set of terms. 'Increased error rate' means the fleet is returning more 5xx than baseline. 'Elevated latency' means P95 is above target but requests are completing. 'Partial availability' means some regions or projects are affected while others are healthy. 'Full recovery' means the metric has returned to baseline for at least 30 minutes. A 'root cause' entry appears in the postmortem within days and names the failing component (Postgres, Auth, PostgREST, Storage, Realtime, Edge Functions). Reading a status page fluently means knowing which of your dependencies each of those services corresponds to in your code.