Skip to main content
All guides
Reference

Supabase glossary: 25 terms every Supabase developer should know

A focused glossary of the language used across the Supabase docs, dashboard, and SDKs — enough to read any thread on the topic without googling every acronym.

Last updated July 18, 2026

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.

FAQ

What is the difference between the anon key and the publishable key?
They are the same thing under two names. Supabase renamed 'anon key' to 'publishable key' to make it obvious the key is safe to publish in a client bundle. Older docs and dashboards still show 'anon'; newer ones say 'publishable'. Either label refers to the JWT-signing public key that clients use to reach the Data API, always paired with RLS as the actual security boundary.
Is Supavisor a drop-in replacement for pgbouncer?
Practically yes for most Supabase users. Supavisor speaks the Postgres wire protocol and behaves like a transaction-mode or session-mode pooler, similar to pgbouncer. It adds tenant awareness and horizontal scaling that a single pgbouncer cannot provide. Client code connects to it the same way it would connect to pgbouncer; you rarely notice the difference except that connection limits scale much further.
Should I use the Data API or an Edge Function?
Prefer the Data API when the call is 'read or write a row the user is allowed to touch'. RLS handles authorization, PostgREST is always warm, and you save a hop. Reach for an Edge Function when the call needs a secret (Stripe, OpenAI, private webhook), orchestrates multiple services, or wraps a slow third-party API you do not want the client to await directly.
What is pgvector used for in Supabase?
pgvector adds a vector column type and similarity operators to Postgres. In Supabase it is the backbone of RAG features: store embeddings alongside your documents, then query the nearest neighbors with a single SELECT. Because it lives inside Postgres you get RLS, joins, and transactions for free, which is a significant simplification over running a separate vector database and syncing state between the two.
Do database webhooks replace triggers?
They build on triggers. A database webhook is a Postgres trigger that calls a small extension which fires an HTTP request. You still get transactional guarantees on the write, and the webhook fires after commit. Use webhooks for side effects that go out to the network (send an email, invalidate a cache, ping an Edge Function). Use plain triggers when the side effect is another SQL statement in the same database.
What is the difference between Realtime broadcast, presence and postgres_changes?
Three channels sharing one WebSocket. postgres_changes streams row-level INSERT/UPDATE/DELETE events from logical replication, filtered by RLS. Presence tracks who is currently subscribed to a channel, useful for cursors and 'X is typing' indicators. Broadcast is a fire-and-forget publish-subscribe channel that never touches the database, useful for ephemeral messages like chat or game moves that do not need durability.
What counts as a Monthly Active User?
Any user who authenticates against your project at least once in the calendar month, including via a magic link, OAuth, refresh token exchange, or anonymous sign-in. A user who signs in five times in a month counts as one MAU. Sign-ups that never complete do not count. Anonymous sessions do count, which surprises teams shipping guest carts at scale; consider expiring anonymous sessions aggressively.
Where does 'Edge Function' end and 'Server Function' begin?
In Supabase-land, Edge Function always means a Deno function deployed to Supabase's edge runtime, invoked over HTTPS. Framework-specific 'server functions' (Next.js server actions, TanStack Start createServerFn, Remix loaders) run in whichever hosting environment you deploy the frontend to, and they call Supabase over HTTPS the same way a client would. The two concepts coexist; Edge Functions are Supabase-native, server functions are framework-native.

Keep reading

See also