Migrate

Migrate from Supabase

Moving from Supabase to Stackap means copying your tables and rows, carrying database functions over by hand, moving stored files and rewriting their URLs, and checking that the app does not depend on Supabase sign-in.

Who this is for

This is the data-side move: the app may stay where it is, or move later. The first thing to settle is sign-in. Stackap has no sign-in service, so an app that uses Supabase's cannot complete this move until it brings its own. If it does not, read on.

The steps below come from the first real copy, a 43-table database of about 25,000 rows and 93 stored files, which now runs on Stackap.

Take inventory first

• Every table, with its row count, which becomes the check after the copy.
• Every function, trigger, view, enum and extension. These are not copied with the rows.
• Every storage bucket, whether it is public or private, and how many objects it holds.
• Every database column that stores a URL to a file.
• Whether any code calls Supabase sign-in, realtime or edge functions.

What does not move automatically

Sign-in

Not provided. Stop here if the app depends on it.

Functions, triggers and views

In the inventory of one large product, 82 of 96 functions existed only in the live database. Extract each and apply it to the new database after the data.

Realtime and edge functions

Not provided.

Policies that read the signed-in user

They stay as Postgres, but nothing sets the user they read; rewrite them.

Storage URLs

Rows that point at files need the new storage host written into them.

How to know it worked

• Every table's row count matches after the final copy.
• Every stored file loads from its new URL, with a sample compared byte for byte.
• Every function the app calls exists in the new database.
• A real request exercises each feature that reads or writes data.

Going back

Keep the Supabase project until you are sure. Pointing the app back is changing its variables and redeploying.

Do not let both databases accept writes at once. Choose a moment, make the final copy, and switch.

Steps

1. Create the project and its database. Create a project and provision its database on Stackap.
2. Copy tables and rows. Run the copy tool. It can be run again and truncates and reloads the tables, so a final copy at cutover is cheap.
3. Apply functions, triggers and views. Create each by hand from the inventory, then run the app's own queries against it.
4. Move the files. Download every object, upload it to the new storage, compare checksums, and rewrite the stored URLs.
5. Point the app at the new data API. Change the data API address and keys in the app's variables, and deploy.
6. Compare. Check row counts table by table, then compare real pages built from the data.

Early-access scope

• Sign-in, realtime and edge functions have no equivalent.
• The copy covers tables and rows only, and functions need the most care.
• The only real move so far is the founder's own site.
• Backups afterwards are daily with no point-in-time recovery, which is a step down from a hosted database.

Questions

Last updated 2026-10-03.