Rebase face à Strapi
Strapi possède le schéma : les types de contenu sont créés dans Strapi, dans les tables de Strapi, et la base de données est un détail d'implémentation. Rebase pointe vers un Postgres que vous avez déjà et travaille avec les tables qu'il y trouve. C'est une différence de nature, et elle décide lequel vous convient avant toute fonctionnalité.
Ses tables, ou les vôtres
Là où ça coince
Strapi modélise les zones dynamiques et les relations via des tables de jointure générées et ses propres métadonnées (components_*). C'est une conception raisonnable pour un CMS qui possède son schéma — mais cela signifie qu'un outil de BI ou une requête SQL brute lit la forme de Strapi et non la vôtre, et que sortir le contenu passe par l'API plutôt que par les tables.
Ce que Rebase fait à la place
Rebase utilise des définitions natives Postgres, portées par Drizzle ORM.
- Les structures de tables restent lisibles — telles qu'un développeur les aurait écrites.
- Se connecte à une base existante. Pas besoin de repartir de zéro.
- Aucun enfermement, car vos données restent interrogeables par n'importe quel outil standard.
Passer d'un environnement à l'autre
Là où ça coince
Déplacer des endpoints personnalisés, des types de contenu et des permissions d'un Strapi local vers la production a historiquement été une étape manuelle, et les étapes manuelles sont là où les déploiements perdent des données.
Ce que Rebase fait à la place
Rebase fonctionne entièrement sur un modèle schéma comme du code.
- Rebase Studio réécrit ses modifications dans votre TypeScript via des transformations d'AST que vous pouvez lire dans le diff.
- Drizzle gère la migration de la base derrière une seule commande CLI.
- Les environnements restent alignés par des commits GitHub, pas par du copier-coller de base de données.
Redémarrages et rechargements
Là où ça coince
Strapi redémarre le serveur quand un type de contenu change, et réagir aux événements de cycle de vie passe par ses propres fichiers de configuration.
Ce que Rebase fait à la place
Rebase est un seul service TypeScript : un changement de schéma est un rechargement à chaud.
- Vous enregistrez un fichier de collection et le serveur de développement régénère le schéma et le SDK, puis recharge à chaud.
- Un serveur Hono standard et des composants React ordinaires, pas un monolithe.
- Le comportement personnalisé est une route d'API que vous écrivez, pas une API de plugins à apprendre.
Ne changez pas
Quand rester sur Strapi
Quand les utilisateurs principaux sont des éditeurs de contenu et que vous voulez une expérience éditoriale soignée dès le départ, ou quand vous avez besoin d'un des plugins de sa place de marché. Strapi y travaille depuis des années. Rebase est la meilleure réponse quand c'est l'application qui compte et que le back-office doit suivre le schéma plutôt que le définir.
Rebase et Strapi, en réponses
Puis-je pointer Rebase vers la base derrière mon projet Strapi ?
Oui, si c'est du PostgreSQL. Rebase lit des tables existantes plutôt que d'en créer : les tables de contenu de Strapi sont lisibles comme des collections. Attention, Strapi modélise certaines relations via ses propres tables de jointure et métadonnées — vous décrirez donc la forme que vous voulez vraiment plutôt que d'importer tel quel le modèle interne de Strapi.
Rebase est-il un CMS headless ?
Pas exactement, et la différence compte au moment de choisir. Un CMS headless possède le schéma et vous livre le contenu par son API. Rebase est un backend : votre schéma Postgres reste le vôtre, l'API et le panneau d'administration sont tous deux générés depuis lui, et la gestion de contenu est une des choses que le panneau fait bien, pas le produit entier.
Et l'écosystème de plugins ?
C'est là que Strapi est devant et il serait malhonnête de prétendre le contraire : sa place de marché est bien plus grande. Rebase s'étend autrement : le panneau d'administration est en React, et tout champ, vue ou page que vous savez construire en React s'y insère avec accès aux hooks internes. Cela convient à une équipe qui écrit déjà du React, et bien moins à une équipe qui veut installer un plugin.
Quand Strapi est-il le meilleur choix ?
Quand les utilisateurs principaux sont des éditeurs de contenu et que vous voulez une expérience éditoriale soignée dès le départ, ou quand vous avez besoin d'un des plugins de sa place de marché. Strapi y travaille depuis des années. Rebase est la meilleure réponse quand c'est l'application qui compte et que le back-office doit suivre le schéma plutôt que le définir.
En quoi l'autorisation diffère-t-elle ?
Strapi a un système de rôles et de permissions dans l'application. Rebase compile ses règles d'accès en sécurité au niveau des lignes de PostgreSQL : les règles sont appliquées par la base de données pour chaque client, pas seulement pour les requêtes qui passent par le framework. Si quelqu'un se connecte avec psql, les politiques sont toujours là.
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 à Strapi.