Is the anon key supposed to be public?

Yes. The anon key is designed to ship in your client, and on its own it is not the problem.

How do I check my own row-level security in five minutes?

In the SQL editor run: select tablename, rowsecurity from pg_tables where schemaname = 'public'.

Do I need to move off Supabase to be production ready?

No, and we usually recommend against it. Supabase is Postgres with good tooling around it, and it runs serious workloads.

We keep hitting connection limits. What actually fixes that?

Almost always pooling plus a shorter query. Serverless functions each open their own connection, so a traffic spike opens hundreds against a database sized for far fewer.

Platform playbook

Make your Supabase backend production-ready

Supabase is an excellent production database, when it is configured like one. Most AI-generated Supabase projects are not, and row-level security is where that shows up first.

Book a Free Call Start with a free check

Supabase

Most common critical finding

Tables with row-level security switched off, or a policy of using (true), reachable with the public anon key.

Production Check: Free, 3–5 days
Typical engagement: 1–3 weeks
Hardening from: $2,000, fixed scope

What we find

Where Supabase apps break in production

What actually goes wrong, and why you would not have spotted it yourself. These are the findings we file most often, not a generic checklist.

Finding 01
Any logged-in person can ask for anyone's rows
Policies that are missing, disabled, or written so permissively that any authenticated user can read any row.
Row-level security gaps
Finding 02
One leaked key bypasses every rule you wrote
The service-role key bypasses every policy. When it reaches client code, the entire security model is gone.
Service-role key exposure
Finding 03
A query that took four milliseconds takes fifteen seconds
Queries that are instant on a thousand rows and time out on a million, because no index was ever added.
Missing indexes
Finding 04
You have backups nobody has ever restored
Point-in-time recovery either not enabled or never actually exercised, which is the same thing on the day you need it.
Untested backups

What we do about it

The Supabase fix list

This is the layer where the highest-severity findings live, whatever built the front end.

How the hardening works

Audit every table and write policies tested against each role
Move all service-role usage server-side and rotate exposed keys
Add indexes based on real query plans, not guesses
Enable point-in-time recovery and run a real restore drill
Add connection pooling sized to your workload
Set up database monitoring with alerts on slow queries and error rates

How it runs

A typical Supabase engagement

Durations from real projects of comparable size. The check is free and everything after it is quoted as fixed scope, so you know the price before we start.

1
Production Check
3–5 days
Every table checked for whether row-level security is enabled and whether its policies actually restrict anything.
2
Policies, roles, keys
Week 1
Policies rewritten per table and tested per role, with the cases kept as automated tests so a future migration that weakens one fails the build.
3
Indexes, pooling, plans
Week 1–2
Indexes added from real execution plans rather than intuition, the worst queries rewritten, and connection pooling put in front of the database and sized for how your app actually connects - which matters most when serverless functions each want a connection of their own.
4
Backups you have restored
Week 2–3
Point-in-time recovery enabled, then an actual restore into a scratch project with the time-to-recover written down in your runbook.

No lock-in

What you keep

Everything we produce belongs to you. If you stop working with us tomorrow, nothing stops running and nothing becomes unmaintainable.

Your accounts and your code
The repository, the cloud accounts, the database and the domain stay in your name.
The report, whatever you decide next
Findings, severity ratings, reproduction steps and effort estimates, written for an engineer.
Infrastructure written down
The environment is defined as code in your repository and comes with a runbook: how to deploy, how to roll back, how to restore, and what to check first.
Your database, portable
It is Postgres, and we keep it that way. Schema and policies live as migration files in your repository, so the project can be recreated anywhere - including on infrastructure you own, if the numbers ever favour it.

Questions

Supabase questions we get asked

If yours is not here, ask it on the call. The first one is free and there is no obligation afterwards.

Yes. The anon key is designed to ship in your client, and on its own it is not the problem.
In the SQL editor run: select tablename, rowsecurity from pg_tables where schemaname = 'public'.
No, and we usually recommend against it. Supabase is Postgres with good tooling around it, and it runs serious workloads.
Almost always pooling plus a shorter query. Serverless functions each open their own connection, so a traffic spike opens hundreds against a database sized for far fewer.