Database

Moving Your Database Between Homes

Take everything (people, clients, findings, files and secrets) from Supabase Cloud, a self-hosted stack or PostgreSQL in your cloud to either of the others, in your own browser, with nothing passing through Pental.

3 min read

Where your database lives is not a decision you are stuck with. The move copies everything from your current database to a new one in any of the three homes, compares the two table by table, and switches the portal over only when you say so. It runs in your own browser, or on your own computer, with your databases’ own credentials. Nothing passes through Pental.

Before you start

  • The new database, set up as its guide describes: Supabase Cloud, self-hosted Supabase or PostgreSQL in your cloud. The move shows the same steps for it.
  • Each database’s own service credential, which only the move uses (see the next section).
  • A quiet moment: while the copy runs, reading and signing in carry on, but saving pauses.

Where each credential is

HomeThe credential, and where to find it
Supabase CloudThe project’s service_role key (it starts eyJ), under API Keys, then Legacy API keys. Supabase refuses its newer sb_secret_ keys from a browser, so a project with only those moves from your computer instead.
Self-hosted SupabaseThe stack’s service key. On its server, in the kit’s folder, grep ^SERVICE_ROLE_KEY= .env prints it.
PostgreSQL in your cloudThe gateway’s setup token (pst_…), from your password manager or beside its deploy script: grep ^SETUP_TOKEN= deploy/*/.deploy-*.env deploy/compose/.env.

They go from your browser to your own databases and nowhere else, are never sent to Pental, and are dropped when the move ends.

Start the move

  1. On your pental.io dashboard, under Portal Configuration, open Database, and under Move your database press Start a move.
  2. Choose the new home and follow its steps, as at setup. The last one takes its credential: for a Supabase project or a stack, its service key; for a gateway, its setup token, and Prepare the new gateway applies the setup SQL through it.
  3. Press Next: your current database and paste the current one’s credential.
  4. Press Start the move, and keep the tab open while it runs.

What happens when you press it

  1. Both databases are checked: reachable, on the same setup SQL, and the new one empty (or you are asked before it is replaced).
  2. Saving pauses on the current database. People can keep reading the portal and signing in; anyone saving is told the database is being moved. Saving resumes by itself if the move stops.
  3. Every row, file and sealed secret is copied straight from one database to the other, through your browser.
  4. The two are compared, table by table. A file uploaded meanwhile is caught here, and you are asked to run it again.
  5. You decide: switch the portal to the new database (the old one is then closed, and everyone signs in again on the new one), or cancel and carry on as before.

Stop the move, or cancel at the end, and saving resumes on the current database with everything as it was. The portal switches only when every count matches, unless you choose otherwise.

From your own computer

For a Supabase project whose newer secret key a browser may not use, or a database too large to leave to a browser tab, the same move runs with Node 18 or later on your own machine. Download pental-move.mjs from Or move from your computer and run it with both addresses; it asks for both credentials there, without showing them.

node pental-move.mjs --from https://current-database --to https://new-database

When it says every count matches, it keeps saving paused and waits. Switch the portal on your dashboard, then type SWITCHED in the terminal to close the old database for good.

Afterwards

The portal now runs on the new database, and everyone signs in again there. The old database refuses changes and tells anyone still on it to reload. Look around, then delete it, or its project, whenever you are ready.

Change Your Mind Whenever You Like

Every plan runs on a database you own, in whichever of the three homes suits you, and moves between them from your dashboard.

Also Worth Reading

Database

Creating Your Database: Three Ways to Run It

Your portal runs on a database you own, in one of three places: Supabase Cloud, self-hosted Supabase, or PostgreSQL in your own cloud. What each is, its pros and cons, and the full guide for each.

Database

Setting Up Your Database on Supabase Cloud

A Supabase project in your own account, set up in five steps the setup checks as you go: the project, its publishable key, the setup SQL, the access token hook, then connect.

Database

Setting Up Your Database on Self-Hosted Supabase

Supabase’s open-source stack on a server you run, from a kit we give you. One script makes its secrets, one command starts it, and it sets up and updates its own database.

Setup guide

Prefer to watch it?

The whole setup recorded, with chapters you can jump to: registering, your own domain, your own database, your own mail server, branding, the first sign-in, and keeping the database updated.

  • 0:00 · Registering, signing in, and the free trial
  • 0:51 · Your name and your firm’s name
  • 0:57 · Custom domain
  • +5 more