Rebase face à Supabase
Les deux placent la sécurité au niveau des lignes dans Postgres. La différence réside dans l'endroit où la politique est écrite : chez Supabase, elle vit dans la base et vous la synchronisez à la main avec votre code ; chez Rebase, c'est un champ sur la collection, compilé en politique, et le même fichier génère l'API, le SDK typé et le panneau d'administration.
La RLS sans le piège
Là où ça coince
Les deux projets mettent l'autorisation dans la sécurité au niveau des lignes de Postgres, et Supabase Studio dispose d'un éditeur de politiques avec un générateur et des modèles. La différence est où la politique vit ensuite : chez Supabase c'est un objet de base que vous tenez à jour à la main avec votre code, chez Rebase c'est un champ de la collection qui se compile en politique — la politique, l'API et le panneau bougent ensemble, et l'écart entre code et base est quelque chose que l'éditeur signale.
Ce que Rebase fait à la place
Rebase écrit la politique là où est la collection. Au lieu d'un objet SQL séparé, vous déclarez la règle en TypeScript et le compilateur en fait une véritable politique Postgres.
- Un éditeur de politiques visuel qui relit la base et signale les écarts.
- Le contexte de la règle est du TypeScript plutôt qu'une jointure écrite à la main.
- Par collection, par champ et par rôle, dans le fichier où vit la collection.
Auto-hébergement, symétrique
Là où ça coince
Auto-héberger Supabase est un chemin pris en charge, avec un fichier Docker Compose publié, et beaucoup d'équipes le font. Ce que vous assumez, ce sont plusieurs services dans plusieurs langages — PostgREST en Haskell, Auth en Go, Realtime en Elixir, Edge Functions sur Deno — chacun avec son propre rythme de versions. Rebase, c'est un processus Node et un Postgres : plus petit à maintenir à jour, pas catégoriquement différent.
Ce que Rebase fait à la place
Rebase, c'est un seul backend Node.js sur Hono et Drizzle ORM standard.
- Un seul service à déployer : Docker, Railway, Fly, ou bare metal.
- Du TypeScript de bout en bout — le langage que votre équipe lit déjà.
- Aucun binaire opaque entre vous et la base de données.
Le schéma comme du code
Là où ça coince
Avec Supabase, la base de données est l'état. Local, préproduction et production divergent à moins que quelqu'un ne les tienne alignés, et versionner RPC, triggers et RLS sous forme de fichiers SQL bruts demande une discipline que personne n'a un vendredi.
Ce que Rebase fait à la place
Dans Rebase la définition du schéma est un fichier TypeScript autonome — config/collections/products.ts — et Git est la source de vérité.
- Rebase Studio utilise la manipulation d'AST pour injecter des champs dans votre code en toute sécurité.
- Les migrations Drizzle sont générées et appliquées depuis la même définition.
- Le code est la source de vérité : les environnements concordent par construction.
Ne changez pas
Quand rester sur Supabase
Quand vous voulez le plus grand écosystème de la catégorie, le plus de tutoriels tiers, ou des edge functions au CDN. Supabase est le produit le plus mature avec une communauté bien plus grande, et si personne en dehors de votre équipe d'ingénierie n'ouvrira jamais le back-office, l'essentiel de ce qu'ajoute Rebase est du poids que vous n'utiliserez pas.
Rebase et Supabase, en réponses
Puis-je utiliser Rebase avec ma base Supabase existante ?
Oui. Rebase se connecte à n'importe quelle base PostgreSQL, y compris celle derrière un projet Supabase, et lit les tables qui s'y trouvent déjà plutôt que d'imposer sa propre forme. Ce qui ne suit pas, c'est la partie de Supabase qui n'est pas Postgres : leur schéma d'auth, leurs edge functions et leurs buckets de stockage sont leurs implémentations — cela, vous le remplaceriez plutôt que vous ne l'importeriez.
Si les deux sont du Postgres avec sécurité au niveau des lignes, qu'est-ce qui change vraiment ?
D'où viennent les politiques. Sur Supabase vous écrivez la RLS en SQL dans un tableau de bord, et une politique qui renvoie zéro ligne en silence est une session de débogage sans pile d'appels. Dans Rebase la politique fait partie de la définition de collection en TypeScript et se compile en véritable politique Postgres à la migration. L'application est identique — c'est Postgres dans les deux cas — mais la règle vit dans votre dépôt, passe en revue de code, et apparaît dans un diff.
Le tableau de bord Supabase n'est-il pas déjà un panneau d'administration ?
C'est un éditeur de tables, ce qui est un autre produit. Il est fait pour le développeur : des lignes brutes, des UUID de clés étrangères, aucun flux de travail, aucun rôle au-delà des rôles de base. Rebase génère une interface pour les gens qui font tourner l'entreprise — formulaires, médias, permissions, tableaux kanban, et vos propres composants React là où le généré ne convient pas — depuis les mêmes définitions de collection qui ont produit l'API.
Quand Supabase est-il le meilleur choix ?
Quand vous voulez le plus grand écosystème de la catégorie, le plus de tutoriels tiers, ou des edge functions au CDN. Supabase est le produit le plus mature avec une communauté bien plus grande, et si personne en dehors de votre équipe d'ingénierie n'ouvrira jamais le back-office, l'essentiel de ce qu'ajoute Rebase est du poids inutile.
Quelle part de réécriture représente le passage de Supabase à Rebase ?
La base de données est la partie qui ne bouge pas — c'est du Postgres des deux côtés. Ce qui change, c'est le client : le client JS de Supabase et le SDK typé de Rebase sont des API différentes, les appels doivent donc être réécrits, et toute politique écrite dans le tableau de bord doit être exprimée sous forme de règles d'accès d'une collection. En pratique, c'est une migration de la couche cliente, pas des données.
Suis-je obligé d'auto-héberger Rebase ?
Non. Auto-hébergez-le et vous possédez les données, le code et la machine sur laquelle il tourne — c'est le mode par défaut et il est pleinement pris en charge. Ou déployez le même projet sur Rebase Cloud, qui tourne aujourd'hui avec de vrais clients et s'ouvre par vagues pendant sa bêta privée, facturé à la ressource plutôt qu'au siège. Votre code est identique dans les deux cas ; l'hébergement est une cible de déploiement, pas un embranchement.
Ne nous croyez pas sur parole.
La comparaison qui compte est celle que vous faites. Pointez Rebase vers une base Postgres que vous avez déjà et voyez comment il tient face à Supabase.