English for Supabase Developers

Supabase has become a widely used open-source alternative to Firebase, giving developers a full Postgres database with authentication, storage, and real-time features out of the box. If you work with Supabase on an international team, you’ll need precise English to describe database policies, real-time behaviour, and edge functions. This guide covers the core vocabulary for Supabase developers.

Key Vocabulary

Row-level security (RLS) — a Postgres feature, central to Supabase’s security model, that restricts which rows a user can read or write based on policies. “We enabled row-level security on the orders table so users can only see their own orders, never anyone else’s.”

Policy — a rule attached to a table under RLS that defines who can perform which operation on which rows. “We wrote a policy that allows a SELECT only when auth.uid() = user_id.”

Real-time subscription — a feature that lets clients receive live updates when rows in a table are inserted, updated, or deleted. “We use a real-time subscription so the dashboard updates instantly when a new order comes in, without polling.”

Edge function — a serverless function, written in Deno, that runs close to the user and can be invoked via HTTP or triggered by database events. “We moved our webhook handler into an edge function so it scales automatically without us managing servers.”

Service role key — a privileged API key that bypasses row-level security, intended only for trusted server-side code. “Never expose the service role key in client-side code — it bypasses every RLS policy we’ve written.”

Anon key — the public API key used by client applications, safe to expose, whose access is fully constrained by RLS policies. “The anon key is embedded in our frontend bundle, but that’s fine — RLS policies enforce what it can actually do.”

Storage bucket — a container for storing files (images, documents, etc.) with its own access policies, similar to RLS for tables. “We created a public storage bucket for avatars and a private one for user documents, each with different access rules.”

Postgres function / trigger — reusable SQL logic stored in the database, often used to enforce business rules or automate side effects on data changes. “We wrote a Postgres trigger that automatically updates the updated_at column whenever a row changes.”

Database webhook — a Supabase feature that calls an external HTTP endpoint whenever a specified database event occurs. “We use a database webhook to notify our billing service the moment a subscription row is updated.”

Discussing Security and Policies

• “We test every RLS policy with a script that runs as different users, to make sure no one can accidentally read another user’s data.”
• “The service role key should only ever be used in server-side code — if it leaks, the isolation policies mean nothing.”
• “We audited all our policies after a near-miss where a policy used USING (true) by mistake, exposing every row.”

Talking About Real-Time and Edge Functions

• “Real-time subscriptions reduced our polling traffic dramatically — the client only re-renders when data actually changes.”
• “We chose an edge function over a traditional server for the webhook handler because it needed to scale to zero when idle.”
• “Database triggers keep our audit log consistent even when data is modified directly in the SQL editor.”

Professional Tips

1. Always explain RLS in terms of the risk it prevents. “Without this policy, any user could query any other user’s private data” makes the stakes clear to reviewers.
2. Never assume the anon key is safe by default. Its safety depends entirely on correctly written RLS policies — say so explicitly in documentation.
3. Log denied policy attempts during testing. It’s easier to explain “this policy blocked an unauthorized read” than to debug a silent empty result set.

Practice Exercise

1. Explain to a new teammate, in 3-4 sentences, the difference between the anon key and the service role key.
2. Write a short explanation (4-5 sentences) of what row-level security does and why it matters for a multi-tenant application.
3. Describe, in plain English, a bug you found where a policy was too permissive, and how you fixed it.