Replacing Supabase in an app exported from Lovable or another AI builder.

Apps from Lovable, Bolt and similar builders talk to Supabase through supabase-js, so a few searches tell you how deep it goes. Run these from the repository root (adjust src to wherever the code lives):

grep -rn "supabase.from(" src | wc -l        # tables queried from the browser
grep -rn "supabase.rpc(" src                   # Postgres functions called directly
grep -rn "supabase.auth" src                   # sign-up, sign-in, sessions
grep -rn "supabase.storage" src                # file uploads and public URLs
grep -rn "functions.invoke" src                # edge functions
grep -rn "supabase.channel" src                # realtime subscriptions
ls supabase/migrations supabase/functions      # schema history and function code

The database is the easy part. The work is in everything Supabase does around it.

Be honest about the count from the first step. If you found dozens of supabase.from calls, several RLS policies, realtime channels and edge functions, you are not swapping a database. You are writing a backend. That can be worth it, but it is not a migration.

A middle path: host the frontend on Canner and keep Supabase as the backend. Set VITE_SUPABASE_URL and the anon key as environment variables before the build, because Vite bakes them in at build time. Supabase has a Montréal region (AWS ca-central-1), so the data can stay in Quebec. Supabase is a US company, though, so a Montréal region does not take it out of reach of US orders; see data sovereignty.

Create the database on your project, then pull the whole Supabase database in with migrate-in. It streams from the source with no local file and needs an empty target:

• Which connection string. Supabase recommends its direct connection for pg_dump-style work. On the Free and Pro plans that connection is IPv6 only; if your side can’t reach it, use the session pooler on port 5432. Never the transaction pooler on 6543 (Supabase docs).
• Why it may stop. Canner restores all or nothing. A Supabase database also holds its own auth and storage schemas, extensions Canner doesn’t install, foreign keys pointing at auth.users, and policies naming the authenticated role or calling auth.uid(). Outside Supabase none of those exist. An extension stops it with: The dump creates an extension that Canner databases do not allow you to install.
• Before you leave, export the user list (select id, email from auth.users). Your tables reference those ids, and you will need them to match people up in the new auth system.

canner db init
export SUPABASE_DB_URL='postgresql://…'   # direct connection, or session pooler (port 5432)
canner db migrate-in --from-env SUPABASE_DB_URL

Dump only the public schema, let a throwaway local Postgres drop whatever depends on Supabase, and import the clean copy. The errors pg_restore prints in step 2 are worth reading slowly: each skipped policy or foreign key is a rule your server code now has to enforce.

# 1. Your tables only, without owners or grants
pg_dump "$SUPABASE_DB_URL" --schema=public --format=custom \
  --no-owner --no-privileges -f supabase.dump

# 2. Restore into a throwaway local Postgres. pg_restore skips what it can't
#    create and prints an error for each one: that list is your to-do list.
docker run -d --name scratch -e POSTGRES_PASSWORD=x -p 5433:5432 postgres:17
pg_restore --no-owner --no-privileges \
  -d postgresql://postgres:x@localhost:5433/postgres supabase.dump

# 3. Dump the clean copy and import it into Canner
pg_dump postgresql://postgres:x@localhost:5433/postgres \
  --format=custom --no-owner -f clean.dump
canner db import clean.dump

• Canner Auth (passkeys). Canner stores the user and the public key; your server verifies a short-lived ES256 token against a public JWKS and keeps no users table. Free up to 1,000 monthly active users, 125,000 on Live. It is passkeys only: no passwords to import, so each existing user enrols a passkey from an emailed link. That email is capped per organization per day (50 on Starter, 5,000 on Live), so moving 2,000 users on Starter takes weeks. On a paid plan your backend can mint enrolment tickets with the secret key instead, which sends no email. The token carries the email; match it to your exported auth.users id on first sign-in. Setup is in the passkeys docs.
• An auth library in your app, using your Canner Postgres. Supabase stores passwords as bcrypt hashes, and Better Auth’s migration guide reads auth.users and auth.identities so users keep their passwords. Social logins need their OAuth callback URLs changed to your new domain.
• Keep Supabase Auth and move everything else. The least code to change, but sign-in still depends on Supabase.

Each Canner project has a private, S3-compatible bucket (how it works). Create a credential under Files → API access and add the values it shows to your environment variables; they are not injected automatically. Object keys must start with the project’s slug, and the client needs forcePathStyle: true.

The endpoint is reachable only from apps running on Canner, not from your laptop or CI. That changes two things. A browser upload that went straight to Supabase now goes to a route in your app, which writes to the bucket. And the one-time copy runs inside the deployed app (a protected admin route that pulls each file from Supabase and writes it to the bucket), or, for a few files, through the upload button on the Files tab. If your tables store full Supabase URLs for avatars and attachments, rewrite them to keys your app serves.