Repository navigation
data copy can't migrate a Supabase database #82
Description
Found while writing a Supabase migration guide for the site.
cloudfall data copy runs pg_dump --no-owner --no-privileges --format custom over the whole source database and pg_restore into the declared one (engine/ansible/roles/cloudfall_data_migration/tasks/main.yml). A typical Supabase database would not restore on a stock Debian PostgreSQL:
- Platform schemas:
auth,storage,realtime,graphql,vault,supabase_functionsand others come along withpublic - Extensions not packaged for Debian:
pg_graphql,pgsodium,supabase_vault,pg_netamong them - Row-level security policies written
TO anonorTO authenticated, roles that do not exist on the target;--no-privilegesskips grants, not policies - References into
auth: functions and policies inpublicthat callauth.uid()or referenceauth.users
The row-count check only covers schema public, so it would not show what was left behind either.
Expected: a way to migrate the application's own schemas from Supabase, with the platform schemas and extensions left out (or handled), and the guide saying plainly that Supabase Auth, Storage and Realtime stay with Supabase or need replacing.
Where it shows: the site rotates "Move off Render" and "Move off Neon"; Supabase is left out until this works.
Activity
shipmill-romamo commentedon Oct 16, 2026
Triage: postponed to after 0.7.0. Confirmed on main (3c2d06c):
engine/ansible/roles/cloudfall_data_migration/tasks/main.ymlrunspg_dump --no-owner --no-privileges --format customover the whole source database with no schema or extension filter, and the row-count check indefaults/main.ymlreads onlytable_schema = 'public'. A Supabase source would carry its platform schemas, Supabase-only extensions and RLS policies onanon/authenticatedinto the restore. Supporting it is a new migration mode, and 0.7.0 is in release candidates, which take bug fixes and broken promises only. Nothing promises Supabase today: #83 kept it out of the site's rotation.The plan:
--schemaper schema, defaultpubliconly), with the row-count check covering exactly those schemaspg_graphql,pgsodium,supabase_vault,pg_net,anon,authenticated), listing each one, instead of a half-failedpg_restoreauth.*as blockers the team must rewrite; Cloudfall won't recreate Supabase AuthThis needs a spec with acceptance criteria before any code. It comes back when the next stable release is out, or sooner if the maintainer promotes it to a feature.
shipmill-romamo commentedon Oct 20, 2026
Triage: feature, back after the 0.7.0 stable release (REVISIT).
Still true on main (348ed73):
cloudfall_data_migrationdumps the whole source database with no schema or extension filter, and its row-count check reads onlypublic. 0.7.0 is out, so the release-candidate bar no longer applies. The plan in the postponement stands (copy only named schemas,publicby default, with the row count covering exactly those; refuse before dumping when they depend on extensions or roles the target lacks; reportauth.*references as blockers), and it goes into a spec with acceptance criteria first. A Supabase guide follows only after a proving run on a real Supabase project, which the spec leaves out of its criteria.Written alongside #81's spec.
The spec PR is being written now (
docs/specs/007-data-copy-schemas.md); I'll put its link and the hold line here. Merging it is the approval.shipmill-romamo commentedon Oct 20, 2026
The spec is in #103 (
docs/specs/007-data-copy-schemas.md). One departure from the plan above: the default stays "every non-system schema", which is whatpg_dumpcopies today, notpubliconly. Narrowing the default would silently stop copying schemas such as Drizzle'sdrizzle. The row-count and empty-target checks then cover every copied schema. A restore now runs--single-transaction, so a failure leaves the target empty instead of half restored. Schemas are chosen with--schemaondata copyand--data-schemaonmigrate.On hold: the build waits on #103, the spec