Leaving Supabase Cloud: the three failures that produce no error

Philip SEOcean — Thu, 01 Oct 2026 11:55:24 +0000

I moved a production multi-tenant SaaS off Lovable and Supabase Cloud onto a single server I own. Ninety-nine tables, 228 row-level-security policies, and a front end that queries the database directly from the browser.

It took about a week. Most of that week went into four or five specific problems, each of which produced a working deployment that was quietly wrong. This is what they were.

Supabase is five programs, not one

Internalise this before planning anything. What the dashboard presents as a single product is a Postgres database plus four services around it:

Component	What it actually does	What I ran
Postgres	your data, your policies	postgres 17, host install
PostgREST	turns `supabase.from()` into SQL over HTTP	`postgrest/postgrest:v16.4`
GoTrue	accounts, passwords, JWTs	`supabase/auth:v2.197.0`
storage-api	file uploads, signed URLs	`supabase/storage-api:v1.79.22`
Edge Functions	Deno workers	deferred

All four are open source and run anywhere. That is why this migration is possible at all.

The complication is the shape of the app. This one is a Vite front end with no backend of its own: the browser queries the database directly. I counted 272 calls to .from(), 28 rpc calls and 26 storage calls in the client bundle. Every one of those arrives at Postgres carrying a JWT, and every one is gated by RLS.

So moving only the database gets you nothing. auth.uid() returns NULL, all 228 policies evaluate false, and every screen goes blank while reporting no error.

`auth.uid()` is not platform magic

I expected this to be the expensive part. It was twenty lines.

auth.uid() reads a session variable. That is the whole mechanism. Whoever holds the connection sets the JWT claims on it before running your query, and the function reads them back:

CREATE OR REPLACE FUNCTION auth.uid() RETURNS uuid
LANGUAGE sql STABLE AS $$
  SELECT COALESCE(
    NULLIF(current_setting('request.jwt.claim.sub', true), ''),
    (NULLIF(current_setting('request.jwt.claims', true), '')::jsonb ->> 'sub')
  )::uuid
$$;

PostgREST already does the setting part — it runs SET LOCAL request.jwt.claims from the bearer token on every request. Give it a function that reads the same variable, and every policy you wrote against Supabase keeps working, word for word.

I did not rewrite a single one of the 228 policies. That is the difference between a week of work and a quarter of it.

Note that the function reads both claim shapes. That is not defensive coding. It is load-bearing, for a reason in the next section.

Five dependencies nobody documents

Your migrations were written against a database that already had things in it. Replay them on clean Postgres and they fail one at a time, each failure revealing a dependency that appears in neither your migration files nor the project docs. I found these in five consecutive runs:

1. The roles. anon, authenticated, service_role. Every policy names them. They do not exist on a fresh cluster.

2. The auth schema and its functions. auth.uid(), auth.role(), auth.jwt(), auth.email(), and an auth.users table for foreign keys to point at.

3. The supabase_realtime publication. Supabase creates it for you. Migrations that call ALTER PUBLICATION supabase_realtime ADD TABLE assume it exists.

4. Extensions in their own schema. pgcrypto installed into public gets dropped along with it when you rebuild. Cloud puts extensions in a separate extensions schema. Copy that, or you lose gen_random_uuid() halfway through a reload.

5. Grants, which fail before the policies. Without GRANT on tables to authenticated, the request is refused at the table level with permission denied — before RLS is ever evaluated. It reads exactly like broken RLS. It isn't. I lost an hour here.

All of it lives in one idempotent SQL file applied before the migrations. Idempotent matters — see trap three.

Three traps that break the app silently

These are the ones worth paying attention to. Each produces a working deployment that is quietly wrong.

Trap 1: GoTrue overwrites `auth.uid()` with a version PostgREST 16 cannot use

GoTrue runs its own migrations on the auth schema at startup and replaces your function. Its version reads only the flat variable request.jwt.claim.sub. PostgREST 16 doesn't set that one — it puts the entire claim set into request.jwt.claims as JSON.

Result: auth.uid() returns NULL on every request, every policy closes, and the app shows empty screens to logged-in users. Nothing is logged. It does not look like a crash. It looks like the data vanished.

The fix is ordering, not fighting. Give GoTrue ownership, let it migrate, then restore your function bodies with CREATE OR REPLACE — which preserves the object identity the policies are bound to, so the swap is invisible to them. Re-apply after every GoTrue image bump.

Trap 2: `session_replication_role = replica` does not skip foreign keys

The standard advice for loading a dump with circular references. It disables triggers on writes. But pg_dump adds foreign keys at the end, as ALTER TABLE ADD CONSTRAINT, and that performs a full validation pass regardless.

Mine failed on users.auth_uid → auth.users, because the auth schema isn't in a public-only dump. The cure wasn't disabling anything: I pulled the thirteen required UUIDs straight out of the COPY public.users block in the dump file and seeded auth.users before loading.

Trap 3: `pg_dump --clean` takes your default privileges with it

--clean drops schema public, and ALTER DEFAULT PRIVILEGES … IN SCHEMA public goes with it. Your grants were correct an hour ago and are gone now, and the symptom is the same permission denied as trap one's.

So the compatibility layer gets applied twice — once before the migrations, once after the data load. Which is why it has to be idempotent from the first line.

One more, less dramatic

pg_net is written in Rust by Supabase and isn't in the PGDG repos. The migrations create it; nothing calls it, because the real HTTP calls came from pg_cron jobs configured through the dashboard. I replaced it with a stub that raises rather than returning NULL. A database making silent outbound HTTP calls that quietly do nothing is a thing you would hunt for weeks.

How I knew it had actually arrived

"The app loads" is not evidence. I built the schema twice by independent routes — replaying all 145 migrations, and restoring a full dump — then compared the results against each other and against the source.


Tables, both routes	99
Rows, matched per table	10,407
Columns	1434 of 1434
Foreign keys	230, zero orphans
RLS policies	228
Functions	26

Row counts per table, not in aggregate — an aggregate match hides two errors that cancel. Orphan check across every foreign key at once. Encoding verified on non-Latin text, which in this app is most of it.

Accounts were recreated through the GoTrue admin API with their original UUIDs — it accepts an explicit id. That one detail meant the application's own user table needed no edits and its foreign key reconnected on all thirteen.

An unplanned finding

Reading every policy carefully is part of the work. That is how I found this, which had been live for seven months:

CREATE POLICY "read_documents" ON storage.objects
  FOR SELECT USING (bucket_id = 'documents');

No TO clause, so it applies to every role — including anon. No tenant check, so it spans every customer. And the anon key ships inside the compiled front-end bundle, where anyone can read it.

Anyone at all could list and download every document belonging to every tenant. The neighbouring bucket's policies were written correctly, so this was one slip rather than a pattern — which is exactly how these survive review.

Rewriting it meant deriving the tenant from the object path, and the paths had two different shapes. I checked the formula against all 360 live objects before switching anything: 360 of 360 agreed with the tenant recorded in the database. Then TO authenticated plus the tenant predicate.

If you are on Supabase and have never read your storage policies line by line, read them today. This one cost nothing to find and would have cost everything to discover the other way.

What this actually costs

Fast: the compatibility layer, the dump and load, the container manifests, routing all four services under one hostname so CORS never comes up, TLS, a deploy pipeline.

Slow:

Reading every policy and every function, because that is where both the traps and the findings are.
Files in storage buckets. Metadata lives in your database; the bytes live on their infrastructure, and without a service_role key you can only export through their own tooling.
Edge function secrets, which are write-only by design. You cannot read them back. Inventory what you set before you cut over.
Scheduled jobs configured through the dashboard rather than in migrations. They are invisible in your repository and they will not come across.
Any value baked into the front-end build. Build-time variables cannot be overridden by the environment at runtime: the container gets the new address and the browser still goes to the old one.

About a week in total, including finding and closing the security hole.

I run three Kubernetes clusters and around twenty services in production across Postgres, MySQL, Redis and object storage. This was my first migration off a vibe-coding platform, and it went well enough that I write it down in case it saves someone the five runs it took me to find those dependencies.

Happy to answer questions in the comments — including on the parts I deferred.

DEV Community: Philip SEOcean