Rebase face à Directus
Les deux lisent une base de données que vous avez déjà plutôt que d'en posséder une, ce qui les rapproche en intention plus que tout le reste de cette liste. Ils divergent sur deux points : où vit le modèle de données — un projet Directus le configure dans ses propres tables, un projet Rebase dans du TypeScript que vous committez — et où les permissions sont appliquées.
Du code, ou l'état de la base
Là où ça coince
Directus garde le modèle de données et la configuration de l'interface dans ses propres tables (directus_collections, directus_fields). Il livre schema snapshot et schema apply pour déplacer cela entre environnements : c'est donc un flux de travail, pas une lacune. La différence est ce que voit le relecteur : un snapshot Directus est un YAML généré décrivant le modèle, une collection Rebase est le TypeScript qui le produit — ce que vous avez édité est ce qui est dans le diff.
Ce que Rebase fait à la place
Rebase adopte une approche schéma comme du code. Chaque collection et chaque champ est défini dans un fichier TypeScript standard.
- Même quand vous ajoutez un champ dans Rebase Studio, le moteur utilise la manipulation d'AST pour écrire le changement dans votre TypeScript.
- Les changements sont committés dans Git.
- Un déploiement est un git pull et une migration : les environnements concordent.
Un framework React, ou un moteur Vue
Là où ça coince
Directus est un moteur d'API bâti sur Vue.js. Tableaux de bord sur mesure, champs spécialisés et vues de données particulières impliquent d'adopter les flux de travail Vue et les schémas d'extension propres à Directus.
Ce que Rebase fait à la place
Rebase est bâti nativement sur React.
- Champs personnalisés, pages entières et widgets de tableau de bord sur mesure sont des composants React ordinaires : l'écosystème que vous utilisez déjà s'applique.
- Utilisez les composants React que vous avez déjà — MUI, Tailwind, Recharts — sans emballage.
- Le backend est une application Hono standard. Une route personnalisée, c'est app.get().
RLS native, ou la couche applicative
Là où ça coince
Directus applique les permissions dans sa propre couche applicative plutôt que dans la sécurité au niveau des lignes de Postgres. Un service qui interroge la base directement n'en rencontre aucune.
Ce que Rebase fait à la place
Rebase compile les mêmes règles en sécurité au niveau des lignes native de Postgres, et vous en donne un éditeur visuel.
- Les règles sont compilées en sécurité au niveau des lignes de Postgres : elles tiennent quelle que soit l'origine de la requête — y compris une session psql qui n'a jamais touché l'API.
- L'éditeur visuel rend une politique lisible, et signale les écarts avec la base.
- Le contexte de sécurité reste le vôtre, dans votre dépôt.
Ne changez pas
Quand rester sur Directus
Quand vous avez besoin aujourd'hui d'une expérience de gestion de contenu mature. Directus a des années de travail dans son interface éditoriale, une place de marché plus grande, et davantage de moteurs de base derrière lui — Rebase est PostgreSQL uniquement, délibérément, car toute l'histoire de la sécurité au niveau des lignes en dépend. Si votre équipe est surtout composée d'éditeurs gérant du contenu, Directus est le produit le plus abouti pour ce travail.
Rebase et Directus, en réponses
Rebase peut-il tourner sur une base que Directus gère déjà ?
Oui. Rebase pointe vers une base PostgreSQL existante et lit les tables qu'il y trouve : un schéma géré par Directus est un point de départ valable. Les tables internes de Directus restent où elles sont et ne sont simplement pas modélisées en collections — vous décrivez les tables qui vous intéressent et laissez le reste tranquille.
À qui appartient le schéma ?
Le vôtre, et c'est la différence centrale. Dans Directus les types de contenu sont créés via son interface, dans son format de migration, dans des tables qu'il gère. Dans Rebase le schéma est du TypeScript dans votre dépôt ; Rebase en génère les tables Postgres et ne réclame jamais de forme à lui. Pointez-le vers une base antérieure à lui et ça marche.
Où le contrôle d'accès est-il appliqué ?
Dans Postgres. Rebase compile les règles d'accès d'une collection en véritables politiques de sécurité au niveau des lignes : une requête qui atteint la base par n'importe quel autre chemin — psql, un rapport, un autre service — reste régie par elles. Directus applique les permissions dans sa couche applicative, devant la base : un moteur réel et bien conçu, mais qui s'arrête à la frontière de Directus.
Quand Directus est-il le meilleur choix ?
Quand vous avez besoin aujourd'hui d'une expérience de gestion de contenu mature. Directus a des années de travail dans son interface éditoriale, une place de marché plus grande, et davantage de moteurs de base derrière lui — Rebase est PostgreSQL uniquement, délibérément, car l'histoire de la sécurité au niveau des lignes en dépend. Si votre équipe est surtout composée d'éditeurs, Directus est le produit le plus abouti pour ce travail.
Rebase me donne-t-il une API en plus d'un panneau d'administration ?
Les deux, depuis la même définition. Une API REST, un SDK typé, des abonnements temps réel et un serveur MCP pour les agents sont générés depuis les collections, et le panneau d'administration consomme cette même API publique sous les mêmes politiques. Aucun canal privé pour les données, aucune seconde copie.
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 à Directus.