Guide Technique de Migration · 6 min de lecture

Migrer un projet Supabase vers Aurabase sans réécrire vos policies RLS

 Affane Daylami · Fondateur· 09 avril 2026

Si vous êtes sur Supabase et que vous lorgnez vers Aurabase (voir notre comparatif détaillé), la bonne nouvelle c'est que le plus dur, c'est de choisir. Le tableau ci-dessous liste précisément ce qui change dans une migration — et c'est court : schéma, policies RLS, SDK, auth et storage restent identiques.

Chez Aurabase, on s'est donné une contrainte forte dès le design : la surface SDK et les conventions RLS devaient être drop-in compatible avec Supabase. Même createClient(), même .from().select().eq(), mêmes policies SQL Postgres. L'idée : si vous voulez partir, partez — on rend ça trivial. Voici le playbook complet.

Audit préalable

Ce qui bouge, ce qui reste

Avant de commencer, listez ce qui va changer et ce qui va rester. Spoiler : la majorité reste.

Schéma PostgresIDENTIQUEpg_dump → pg_restore. Extensions, triggers, functions, indexes — tout passe.

Policies RLSIDENTIQUEMême syntaxe. auth.uid(), auth.role(), auth.jwt() fonctionnent tels quels.

SDK JavaScript95% IDENTIQUERemplacez @supabase/supabase-js par @aurabase/aurabase-js. Même API chainable.

Auth flowsIDENTIQUEsignUp, signInWithPassword, signInWithOAuth, mfa — mêmes noms, mêmes signatures.

Storage APIIDENTIQUEaura.storage.from(bucket).upload(...) · compat S3 · policies RLS transférables.

RealtimeIDENTIQUEchannel().on("postgres_changes", ...) inchangé. Presence + broadcast pareils.

Edge FunctionsIDENTIQUEDeno.serve() collé tel quel dans l'éditeur Studio. La CLI aura functions deploy vise un chemin distinct (Rust compilé en WASM).

DashboardDIFFÉRENTStudio Aurabase · on vous aide à retrouver vos repères.

Étape 1

Créer le projet Aurabase cible

Créez un nouveau projet Aurabase avec la CLI officielle, puis liez ce dossier au projet pour que les commandes suivantes s'y appliquent automatiquement.

terminal

BASH

# Compte Aurabase + CLI
npm i -g @aurabase/cli
aura login
# Créer le projet (moteur Postgres)
aura projects create my-app --engine postgres
# Lier ce dossier au projet créé
aura link --project-id <uuid-du-projet>
# Récupérer les clés API du projet lié
aura projects api-keys

Étape 2

Dump Supabase, restore Aurabase

Un pg_dump / pg_restore standard : Aurabase expose une chaîne de connexion Postgres directe pour chaque projet (Studio → Paramètres → Connexion), pas besoin de transformation intermédiaire.

terminal

BASH

# Récupérer la connection string Supabase depuis leur dashboard
export SUPABASE_DB_URL="postgresql://postgres:...@db.xxx.supabase.co:5432/postgres"
# Dump du schéma public (sans les schémas système Supabase)
pg_dump "$SUPABASE_DB_URL" \
  --schema=public \
  --no-owner --no-acl \
  --format=custom \
  -f supabase-dump.pgdump
# Récupérer la chaîne de connexion Aurabase (Studio → Paramètres → Connexion)
# Le paramètre ?search_path= est OBLIGATOIRE : il route vers le schéma de votre projet
export AURA_DB_URL="postgresql://aura:...@<host>:5432/aura_db_master?search_path=project_<id>"
# Restore avec pg_restore standard
pg_restore --no-owner --no-acl -d "$AURA_DB_URL" supabase-dump.pgdump
# Regénérer les types TypeScript
aura db generate > src/aurabase.types.ts

Étape 3

Migrer les utilisateurs

Un point à corriger par rapport à ce qu'on affirmait ici auparavant : Aurabase hache les mots de passe avec Argon2id, mais Supabase (GoTrue) hache les siens par défaut avec bcrypt — les deux formats ne sont pas interchangeables. Vos utilisateurs devront donc redéfinir leur mot de passe une fois, comme sur la plupart des migrations.

Aurabase ne propose pas aujourd'hui d'outil d'import en masse depuis Supabase. Deux options : laisser vos utilisateurs se réinscrire eux-mêmes (signUp avec la même adresse email), ou les recréer un par un côté admin avec aura auth users create --email <email> avant de déclencher une réinitialisation de mot de passe.

Info

Les sessions actives côté Supabase ne sont pas portées (impossible techniquement — chaque plateforme signe ses JWT avec sa propre clé). Les utilisateurs devront se reconnecter, avec leur nouveau mot de passe.

Étape 4

Adapter le code client

Une recherche/remplacement suffit pour 95% des cas.

lib/supabase.ts → lib/aurabase.ts

TYPESCRIPT

// AVANT (Supabase)
import { createClient } from '@supabase/supabase-js'
export const supabase = createClient(url, key)
// APRÈS (Aurabase)
import { createClient } from '@aurabase/aurabase-js'
export const aura = createClient(url, projectId, key)
// Le reste du code ne change pas :
await aura.from('posts').select('*').eq('author_id', userId)

Étape 5

Déployer les Edge Functions

Aurabase propose deux chemins pour les Edge Functions : l'éditeur de code du Studio (runtime Deno, identique à Supabase — collez votre fonction telle quelle) et la CLI aura functions deploy, qui vise un chemin distinct pour des fonctions écrites en Rust et compilées en WASM. Pour migrer du code Deno existant sans réécriture, passez par le Studio.

functions/hello/index.ts

TYPESCRIPT

// Fonctionne à l’identique, collée telle quelle dans l’éditeur Studio
Deno.serve(async (req) => {
  const { name } = await req.json()
  return new Response(JSON.stringify({ hello: name }))
})

Cutover

Bascule DNS et mise en production

Deux stratégies possibles. On recommande la première pour 99% des cas.

Cutover direct — changez AURA_URL et AURA_ANON_KEY dans vos env vars, redéployez. Les users se reconnectent, tout fonctionne. Recommandé pour la majorité des projets.
Dual-write temporaire — écrivez dans Supabase + Aurabase simultanément pendant 48h, vérifiez la cohérence des tables critiques manuellement (comptage de lignes, checksums), puis coupez Supabase. À privilégier pour les apps critiques.

Aide

On est là si ça coince

Pour les projets volumineux ou avec des contraintes de conformité strictes, notre équipe peut vous accompagner sur la migration. Contactez-nous pour une offre adaptée à votre projet.

Demander un accompagnement →