Migration

Import into Kuunda Cloud

Export the public schema from your external database, then import it into a Kuunda project. Wizard: Project → Settings → Data import (https://app.kuunda-cloud.com/{ref}/settings/import).

1. Get the credentials (source)

Source dashboard (e.g. Supabase → Connect and Settings → API). Three values, three uses.

Password with @, #, % : use $env:PGPASSWORD, do not put it in the dump URI. Kuunda never stores the URI.

2. Create the Kuunda project

1. Console → New project.
2. Settings → API — note URL https://xxxxxxxx.kuunda-cloud.com, anon key, service_role key (server only), schema proj_ + 32 hex.
3. If you also migrate Auth: Auth → Providers (Site URL, Redirect URLs, OAuth) before importing users. Google callback: see Google sign-in.

3. Export the database (PowerShell)

Install the PostgreSQL client (pg_dump). Directconnection: host db.{ref}.supabase.co, port 5432, user postgres. Do not dump the auth / storage schemas (dedicated buttons in Kuunda).

Two files: schema first (tables, RLS), then data.

$env:PGSSLMODE = "require"
$env:PGPASSWORD = 'PASSWORD'

pg_dump --schema-only --no-owner --no-acl -n public `
  -h db.VOTRE_REF.supabase.co `
  -p 5432 `
  -U postgres `
  -d postgres `
  -f schema.sql

pg_dump --data-only --no-owner -n public `
  -h db.VOTRE_REF.supabase.co `
  -p 5432 `
  -U postgres `
  -d postgres `
  -f data.sql

Remove-Item Env:PGPASSWORD

Check:

Get-Item schema.sql, data.sql | Select-Object Name, Length
Get-Content schema.sql -TotalCount 5

The schema.sql file must contain CREATE TABLE / policies. If pg_dump fails on the pooler: you are not on the db.…supabase.co.

Bash:

export PGSSLMODE=require PGPASSWORD='PASSWORD'
pg_dump --schema-only --no-owner --no-acl -n public \
  -h db.VOTRE_REF.supabase.co -p 5432 -U postgres -d postgres -f schema.sql
pg_dump --data-only --no-owner -n public \
  -h db.VOTRE_REF.supabase.co -p 5432 -U postgres -d postgres -f data.sql
unset PGPASSWORD

4. Import into Kuunda

Order to follow:

1. schema.sql — tables, indexes, RLS policies
2. Import auth.users
3. data.sql — rows
4. Import Storage

Source

1. Choose BaaS export (public schema) (Postgres / Neon: the matching card).
2. Paste thePostgres URI (password already in the URI).
3. Source schema: public.
4. Paste Storage URL + source service_role key (if you want the files).
5. Analyse source (counts).

Script + Apply — schema

1. Step Script: load schema.sql.
2. Transform → proj_… (replaces public with the tenant schema).
3. Step Apply → Apply on Kuunda.

Missing extensions (pgcrypto, etc.): Database → Extensions before re-applying. The SQL ignores FKs to auth.users / storage.*, BaaS roles and blocked CREATE EXTENSION .

Auth accounts

Go back to the Source step → Import auth.users (reads the Postgres URI).

• Kept: UUID, bcrypt hash, metadata.
• Not migrated: JWT sessions, auth.identitiesrows, accounts without email.

Users sign in again. First OAuth login: link by email (same UUID if already imported).

Script + Apply — data

1. Step Script: load data.sql.
2. Transform then Apply on Kuunda.

Storage

Step Source → Import Storage. Without URL + key: empty buckets only.

Check

Step Check → Source ↔ Kuunda report. Counts must match.

Realtime: synced at import. Missing tables → Realtime → Sync publication.

5. Limits and sources

Wizard cards: BaaS export (public schema), PostgreSQL, Neon, File / SQL script. A supabase.co / pooler.supabase.com host is recognized for SSL. There is no “Firebase” card: see Migrate from Firebase.

PostgreSQL / RDS / VPS : same pg_dumpcommands, replace host / user / database. PostgreSQL card in the wizard. No Auth/Storage button unless the source has those schemas.

Neon : Migrate from Neon (URI + sslmode=require ).

App cutover, OAuth, production: Full migration (SDK + production).