Rebase gegen Directus
Beide lesen eine Datenbank, die du schon hast, statt eine zu besitzen — das macht sie in der Absicht ähnlicher als alles andere auf dieser Liste. Sie trennen sich in zwei Punkten: wo das Datenmodell lebt — ein Directus-Projekt konfiguriert es in eigenen Tabellen, ein Rebase-Projekt in TypeScript, das du committest — und wo Berechtigungen durchgesetzt werden.
Code, oder Datenbankzustand
Wo es wehtut
Directus hält Datenmodell und Interface-Konfiguration in eigenen Tabellen (directus_collections, directus_fields). Es liefert schema snapshot und schema apply, um das zwischen Umgebungen zu bewegen — das ist also ein Workflow, keine Lücke. Der Unterschied ist, was der Reviewer sieht: Ein Directus-Snapshot ist eine generierte YAML-Datei, die das Modell beschreibt, und eine Rebase-Collection ist das TypeScript, das es erzeugt — was du bearbeitet hast, ist das, was im Diff steht.
Was Rebase stattdessen macht
Rebase verfolgt einen Schema-als-Code-Ansatz. Jede Collection und jedes Feld wird in einer normalen TypeScript-Datei definiert.
- Selbst wenn du ein Feld in Rebase Studio hinzufügst, schreibt die Engine die Änderung per AST-Manipulation in dein TypeScript.
- Änderungen werden in Git committet.
- Ein Deployment ist ein git pull und eine Migration — die Umgebungen stimmen überein.
Ein React-Framework, oder eine Vue-Engine
Wo es wehtut
Directus ist eine API-Engine auf Vue.js. Eigene Dashboards, spezialisierte Eingaben und besondere Datenansichten heißen: Vue-Workflows und Directus' eigene Erweiterungsmuster übernehmen.
Was Rebase stattdessen macht
Rebase ist nativ auf React gebaut.
- Eigene Felder, ganze neue Seiten und maßgeschneiderte Dashboard-Widgets sind gewöhnliche React-Komponenten — das Ökosystem, das du schon nutzt, greift.
- Nutz die React-Komponenten, die du schon hast — MUI, Tailwind, Recharts — ohne Wrapper.
- Das Backend ist eine normale Hono-App. Eine eigene Route ist app.get().
Native RLS, oder die Anwendungsschicht
Wo es wehtut
Directus setzt Berechtigungen in der eigenen Anwendungsschicht durch statt in Postgres-Row-Level-Security. Ein Dienst, der die Datenbank direkt abfragt, trifft auf keine davon.
Was Rebase stattdessen macht
Rebase kompiliert dieselben Regeln zu nativer Postgres-Row-Level-Security und gibt dir einen visuellen Editor darüber.
- Regeln werden zu Postgres-Row-Level-Security kompiliert und halten damit unabhängig davon, woher die Query kam — auch bei einer psql-Sitzung, die die API nie berührt hat.
- Der visuelle Editor macht eine Policy lesbar und meldet Drift gegenüber der Datenbank.
- Der Sicherheitskontext bleibt deiner, in deinem Repository.
Nicht wechseln
Wann du bei Directus bleiben solltest
Wenn du heute eine reife Content-Management-Erfahrung brauchst. Directus hat Jahre Arbeit in seiner redaktionellen Oberfläche, einen größeren Marktplatz und mehr Datenbank-Engines dahinter — Rebase ist bewusst nur PostgreSQL, weil die ganze Row-Level-Security-Geschichte davon abhängt. Wenn dein Team vor allem Redakteure sind, die Inhalte pflegen, ist Directus dafür das fertigere Produkt.
Rebase und Directus, beantwortet
Kann Rebase auf einer Datenbank laufen, die Directus schon verwaltet?
Ja. Rebase richtet sich auf eine bestehende PostgreSQL-Datenbank und liest die Tabellen, die es findet — ein von Directus verwaltetes Schema ist ein gültiger Ausgangspunkt. Directus' eigene Verwaltungstabellen bleiben, wo sie sind, und werden einfach nicht als Collections modelliert: Du beschreibst die Tabellen, die dich interessieren, und lässt den Rest in Ruhe.
Wem gehört das Schema?
Dir, und das ist der zentrale Unterschied. In Directus entstehen Content-Typen über seine Oberfläche, in seinem Migrationsformat, in Tabellen, die es verwaltet. In Rebase ist das Schema TypeScript in deinem Repository; Rebase erzeugt daraus die Postgres-Tabellen und verlangt nie eine eigene Form. Richte es auf eine Datenbank, die älter ist als es selbst, und es funktioniert.
Wo wird die Zugriffskontrolle durchgesetzt?
In Postgres. Rebase kompiliert die Access-Rules einer Collection in echte Row-Level-Security-Policies — eine Query, die die Datenbank auf irgendeinem anderen Weg erreicht (psql, ein Report, ein anderer Dienst), unterliegt ihnen weiterhin. Directus setzt Berechtigungen in seiner Anwendungsschicht vor der Datenbank durch: eine echte, gut gebaute Engine, die aber an Directus' Rand endet.
Wann ist Directus die bessere Wahl?
Wenn du heute eine reife Content-Management-Erfahrung brauchst. Directus hat Jahre Arbeit in seiner redaktionellen Oberfläche, einen größeren Marktplatz und mehr Datenbank-Engines dahinter — Rebase ist bewusst nur PostgreSQL, weil die Row-Level-Security-Geschichte davon abhängt. Wenn dein Team vor allem Redakteure sind, ist Directus dafür das fertigere Produkt.
Bekomme ich bei Rebase neben dem Admin-Panel auch eine API?
Beides, aus derselben Definition. Eine REST-API, ein typisiertes SDK, Realtime-Subscriptions und ein MCP-Server für Agenten entstehen aus den Collections, und das Admin-Panel ist ein Konsument genau dieser öffentlichen API unter denselben Policies. Es gibt keinen privaten Rückkanal für Daten und keine zweite Kopie davon.
Muss ich Rebase selbst hosten?
Nein. Hoste es selbst, und dir gehören die Daten, der Code und die Maschine, auf der es läuft — das ist die Voreinstellung und wird voll unterstützt. Oder deploy dasselbe Projekt auf Rebase Cloud, das heute mit echten Tenants läuft und während der Private Beta in Wellen öffnet, abgerechnet pro Ressource statt pro Sitz. Dein Code ist in beiden Fällen identisch; Hosting ist ein Deployment-Ziel, keine Abzweigung.
Glaub uns nicht einfach.
Der Vergleich, der zählt, ist der, den du selbst machst. Richte Rebase auf ein Postgres, das du schon hast, und sieh, wie es sich neben Directus hält.