Is Your Supabase App Production-Ready? Measure It, Do Not Guess

The Short Answer

“Production-ready” is not a property of Supabase. It is a property of the decision you did or did not make about where tenancy lives — and most teams never made it explicitly. They wrote a policy when a feature needed one, which is how you end up with forty individually reasonable policies and no model.

That is diagnosable in an afternoon. Four numbers, four SQL queries against your own project, and thresholds that are deliberately uncomfortable: three of the four have a passing value of all or zero, because partial enforcement of a security boundary is not partial safety.

Why the Checklists Do Not Help

There is no shortage of Supabase launch checklists, and they are not wrong. Enable RLS. Do not ship the service key. Set up backups. The problem is that a checklist is a list of topics, and every team reads it, nods at each line, and learns nothing they did not already suspect. Nobody finishes a checklist knowing whether they have a problem.

A measurement is different because it can come back badly. It produces a number you did not know, it can contradict you, and it converts “we should probably look at RLS sometime” into “nine of our sixty-one tables are readable with the anon key.” One of those sentences gets scheduled.

The Four Measurements

Run all four. Individually each is a weak signal; together they describe whether a boundary exists or whether one was approximated forty times.

1. RLS coverage

The fraction of tables in your public schema with row-level security enabled. The passing value is 100% and there is no sensible argument for less, because Supabase exposes that schema over PostgREST: a table without RLS is readable by anyone holding the anon key, and the anon key is in your client bundle.

The objection is always the same — nothing queries that table directly. That is a statement about your code, not about what is reachable. The table is an HTTP endpoint whether or not you wrote a client for it.

2. Policy-free tables

Tables with RLS enabled and no policy attached. This is not the dangerous failure — it is the confusing one. RLS with no policy denies everything over PostgREST, so the table looks locked down, and it genuinely is.

The cost arrives later. Somebody hits a permissions error in a hurry and reaches for the service-role key or a SECURITY DEFINER function to make it go away, and now the table is reachable by a path with no boundary on it at all. Measurement two is how measurement three gets worse.

Which is why the threshold is not zero. A table with no policy because nothing should ever reach it over the API is a decision. A table with no policy because nobody got to it yet is a deadline.

3. Bypass surface

Every code path that runs with the service-role key, plus every SECURITY DEFINER function. Both legitimately exist. A webhook handler with no user identity has nothing to filter on; a function that deliberately reads across tenants for an admin view is a real requirement.

The threshold is therefore not a count but a question: can you recite them? A bypass surface you can list from memory is a set of decisions. One you have to go and grep for is a set of accidents, and it is the single most common source of the symptom teams actually report — the same screen showing different things to different people.

4. Storage alignment

Storage policies are a separate policy language from table RLS, evaluated against a different object, and they are the layer most often left open. A file reference secured in the database is not a file secured in the bucket. For every bucket, ask whether its object policy agrees with the policy on the table that references those files. Any bucket you cannot answer for counts against you.

Running Them

The first two are single queries against the Postgres catalog. Paste them into the SQL editor in your Supabase dashboard; both are read-only and neither touches your data.

select c.relname            as table_name,
       c.relrowsecurity     as rls_enabled
from   pg_class c
join   pg_namespace n on n.oid = c.relnamespace
where  n.nspname = 'public'
  and  c.relkind = 'r'
order  by c.relrowsecurity, c.relname;

select c.relname as table_name
from   pg_class c
join   pg_namespace n on n.oid = c.relnamespace
where  n.nspname = 'public'
  and  c.relkind = 'r'
  and  c.relrowsecurity
  and  not exists (
         select 1 from pg_policy p where p.polrelid = c.oid
       )
order  by c.relname;

Measurement three is a repository search rather than a query — grep for your service-role environment variable and for SECURITY DEFINER, then read each result instead of counting it. Measurement four is a manual pass over your buckets, which is tedious, and which is exactly why it is the one usually skipped.

One warning, because it is the mistake I see most often when teams try to shortcut this: do not ask a language model to audit the schema for you. It will produce a confident, well-written assessment of a database it cannot see, listing policies that sound plausible for an application like yours. Deterministic queries first, interpretation second — the same ordering that repository-level code review requires, and for the same reason.

What Good Looks Like

For contrast, the shape these numbers take on a platform where tenancy was decided once and early. On a multi-tenant utility and IoT platform I led as fractional CTO, row-level security ran across a 31-table PostgreSQL schema serving three separate portals — admins, agencies and tenants.

Three audiences, one boundary, expressed the same way in every table. The count of tables was never the hard part. Deciding once what a tenant was, and then not revisiting it, was.

The same principle, one layer up, is what SureCiteAI’s four-layer isolation does: database RLS, then per-tenant vector namespaces, then session tokens carrying tenant context, then subdomain routing. Four layers, each of which independently prevents the leak. That is what “it holds at 3am” costs.

What To Do On Monday

Run measurements one and two before lunch; they are two queries and they will tell you most of what you need. If coverage is 100% and there are no policy-free tables, you are in better shape than most and the remaining work is the bypass surface. If coverage is not 100%, stop reading and go and fix that, because nothing else on the list matters while a table is openly readable.

And if the numbers come back badly, the useful reframe is that you have found it in the cheapest week it will ever be. The cost of settling tenancy does not rise with the size of your schema. It rises with how many places the old assumption has already been copied.

If you would rather have someone else run this against your project and tell you what it means, that is a Supabase architecture review.

Frequently Asked Questions