Private pilotCurrent availability and limits ↗
Docs/Platform·
.mdES

Migration in and out

Status: In development (ops.migration)

Status: In development (ops.export)

There is no self-service migration or export in Plurabase yet. During the pilot, moving a project in or out is done with the operator. Because a Plurabase project runs the same open-source services as self-hosted Supabase, the data formats are standard: PostgreSQL 17 dumps, Storage objects and Deno function source. See the facts page for status words.

Migration jobs (in development)

The repository has code for migration jobs that an owner or admin of the target project starts with the source's session pooler connection string and a Supabase access token. A preflight report lists every incompatibility before anything is written. The job then copies the database with its Auth users, Storage objects and Edge Functions, verifies the copy against row checksums taken from one source snapshot and compares objects and functions, and gives a cutover checklist. A reset empties the target again; after verification it deletes nothing if the target changed since. A separate plan reads a Vercel project's configuration files and environment variable names and says whether its frontend can be served by Sites as a static build. None of this is deployed or has run against a real Supabase project, so the steps below are still how a project moves today.

From Supabase to Plurabase

  1. Inventory (read-only). The operator's collector reads the source project's metadata with a Supabase personal access token typed at a hidden prompt, never on the command line. It records the PostgreSQL version, tables, views, RLS policies, foreign keys, functions and triggers in public, and counts for Auth, Storage, Functions and Realtime. It does not export rows. Anything it cannot inspect is reported as unknown, not as unused.
  2. Plan. The console's migration page (/platform/migration.html) checks the inventory and lists what needs attention, such as Vault keys, other schemas or a different PostgreSQL version. Planning changes nothing.
  3. Database. The operator restores the schema and data into the new project and compares row counts per table. Keep the platform schemas PostgREST needs (graphql, graphql_public). One rehearsal with an owner project restored every table, row and foreign key into an isolated database on 2026-10-15; logging in as a migrated user was not tested.
  4. Auth. Users and their password hashes travel with the auth schema. Existing sessions end because the new project has its own JWT secret, so users sign in again.
  5. Storage. Objects are copied through the Storage API and checked by count and size. Copying Docker volumes is not a migration.
  6. Edge Functions. Redeploy each function and enter its secrets again. Vendor any remote npm or jsr import into local files first.
  7. Frontend. Publish a static build on Sites, or keep the frontend where it is and change its API URL and publishable key.
  8. Cutover. Pause writes on the source, move the final data, then switch clients. There is no zero-downtime cutover.

From Plurabase to Supabase or elsewhere

The same steps run in reverse: a PostgreSQL dump of your schemas and the auth schema, a copy of Storage objects, and your function source. They restore into Supabase Cloud, self-hosted Supabase or any PostgreSQL 17 server. Your Site's ZIP is an ordinary static build. Self-service export exists as code: an owner or admin requests it, and the project's database (every schema, auth and storage included), Storage objects, function code and secrets and auth settings arrive as one file encrypted with age that only the requester can decrypt, downloaded once through a short-lived link, with an import tool for self-hosted Supabase. It has no console button yet and is not enabled on the pilot host, so until it is (milestone M3) ask the operator for the dump and the objects.

Things to check before a cutover

  • Vault secrets and OAuth client secrets never move on their own; set them up again.
  • New writes made after a cutover are not copied back if you return to the source.
  • Test the application end to end against the new project before switching users.