Migration

Importer vers Kuunda Cloud

Exportez le schéma public de votre base externe, puis importez-le dans un projet Kuunda. Assistant : Projet → Réglages → Import données (https://app.kuunda-cloud.com/{ref}/settings/import).

1. Récupérer les identifiants (source)

Dashboard source (ex. Supabase → Connect et Settings → API). Trois valeurs, trois usages.

Valeur	Sert à	Où la coller
URL projet https://…………………….supabase.co Settings → API → Project URL (souvent aussi dans Authentication → URL Configuration).	Copier les fichiers Storage depuis la source.	Kuunda Import, étape Source → champ URL Storage source.
URI Postgres postgresql://postgres:PASSWORD@aws-1-….pooler.supabase.com:5432/postgres Connect → URI (session, port 5432). Pas le port 6543.	Comptage des tables, import `auth.users`, liste des buckets.	Kuunda Import, étape Source → champ URI Postgres. Remplacez `PASSWORD` par le mot de passe réel.
Mot de passe DB PASSWORD Settings → Database (Reset si oublié).	Authentifier `pg_dump` et l’URI.	Terminal : `$env:PGPASSWORD`. Aussi dans l’URI à la place de `:PASSWORD@`. Pas dans le SQL.
Clé service_role source eyJ… Settings → API → Legacy → service_role.	Télécharger le contenu des objets Storage.	Kuunda Import, étape Source → Clé service_role Storage.

Mot de passe avec @, #, % : utilisez $env:PGPASSWORD, ne le mettez pas dans l’URI du dump. L’URI n’est jamais stockée par Kuunda.

2. Créer le projet Kuunda

Console → Nouveau projet.
Réglages → API — noter URL https://xxxxxxxx.kuunda-cloud.com, clé anon, clé service_role (serveur uniquement), schéma proj_ + 32 hex.
Si vous migrez aussi Auth : Auth → Providers (Site URL, Redirect URLs, OAuth) avant l’import des users. Callback Google : voir Connexion Google.

3. Exporter la base (PowerShell)

Installez le client PostgreSQL (pg_dump). Connexion directe: hôte db.{ref}.supabase.co, port 5432, user postgres. Ne pas dumper les schémas auth / storage (boutons dédiés dans Kuunda).

Deux fichiers : d’abord le schéma (tables, RLS), ensuite les données.

$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

Vérifier :

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

Le fichier schema.sql doit contenir du CREATE TABLE / politiques. Si pg_dump échoue sur le pooler : vous n’êtes pas sur l’hôte 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. Importer dans Kuunda

Ordre à respecter :

schema.sql — tables, index, politiques RLS
Importer auth.users
data.sql — lignes
Importer Storage

Source

Choisir Export BaaS (schéma public) (Postgres / Neon : la carte correspondante).
Coller l’URI Postgres (mot de passe déjà dans l’URI).
Schéma source : public.
Coller URL Storage + clé service_role source (si vous voulez les fichiers).
Analyser la source (comptage).

Script + Appliquer — schéma

Étape Script: charger schema.sql.
Transformer → proj_… (remplace public par le schéma tenant).
Étape Appliquer → Appliquer sur Kuunda.

Extensions manquantes (pgcrypto, etc.) : Database → Extensions avant de réappliquer. Le SQL ignore les FK vers auth.users / storage.*, les rôles BaaS et les CREATE EXTENSION bloquées.

Comptes Auth

Revenir à l’étape Source → Importer auth.users (lit l’URI Postgres).

Conservé : UUID, hash bcrypt, métadonnées.
Non migré : sessions JWT, lignes auth.identities, comptes sans e-mail.

Les utilisateurs se reconnectent. Premier login OAuth : liaison par e-mail (même UUID si déjà importé).

Script + Appliquer — données

Étape Script: charger data.sql.
Transformer puis Appliquer sur Kuunda.

Storage

Étape Source → Importer Storage. Sans URL + clé : buckets vides seulement.

Contrôle

Étape Contrôle → Rapport source ↔ Kuunda. Les comptages doivent matcher.

Realtime : sync à l’import. Tables manquantes → Realtime → Synchroniser la publication.

5. Limites et sources

Ressource	Limite assistant
Fichier SQL	~20 Mo — découper si plus gros
Comptes Auth	2 000
Storage	50 buckets, 2 000 fichiers, 50 Mo/fichier
Tables inventoriées	500

Cartes de l’assistant : Export BaaS (schéma public), PostgreSQL, Neon, Fichier / script SQL. Un hôte supabase.co / pooler.supabase.com est reconnu pour le SSL. Il n’y a pas de carte « Firebase » : voir Migrer depuis Firebase.

PostgreSQL / RDS / VPS : mêmes commandes pg_dump, remplacez l’hôte / user / base. Carte PostgreSQL dans l’assistant. Pas de bouton Auth/Storage sauf si la source a ces schémas.

Neon : Migration depuis Neon (URI + sslmode=require ).

Appliquer l’app, OAuth, cutover : Migration complète (SDK + production).