Rebase gegen Appwrite
Beide geben dir Auth, eine Datenbank, Storage, Functions und Realtime hinter einer API. Der Unterschied ist die Datenbank. Die von Appwrite gehört der Plattform: Du erreichst sie über Appwrites API, und die native SQL-Option gibt es nur ohne die Plattform. Rebase erzeugt die API, das typisierte SDK und ein Admin-Panel auf einem Postgres, das dir gehört, und setzt den Zugriff in der Datenbank selbst durch.
Die Plattform oder SQL — oder beides
Wo es wehtut
Appwrite 2.0 betreibt TablesDB standardmäßig auf PostgreSQL, mit Relationship-Spalten und Transaktionen. Die Datenbank gehört aber Appwrite: Es legt das Schema an und verwaltet es, du erreichst die Daten über seine Query-API, REST oder GraphQL statt über SQL, und es gibt keinen dokumentierten Weg, es auf die Tabellen einer bestehenden Datenbank zu richten. Appwrite Cloud bietet inzwischen auch natives PostgreSQL mit vollem SQL an — laut eigener Dokumentation ohne Appwrite-Schicht dazwischen. Du entscheidest dich zwischen der Plattform und der Datenbank.
Was Rebase stattdessen macht
Rebase erzeugt die Plattform auf einem Postgres, das dir gehört — es gibt nichts, zwischen dem du wählen müsstest.
- Richte es auf eine bestehende Datenbank, und es leitet die Collections aus den vorhandenen Tabellen ab.
- Die generierte API und psql lesen dieselben Tabellen, also funktionieren BI-Werkzeuge und ETL-Jobs weiter.
- Reicht die generierte API nicht, schreibst du den Join oder die View in SQL.
Berechtigungen im Server, oder in der Datenbank
Wo es wehtut
Appwrites Berechtigungsmodell ist gut: Lesen, Erstellen, Ändern und Löschen auf Tabellen und Zeilen, für alle Besucher, angemeldete Nutzer, einen Nutzer, ein Team, eine Team-Rolle oder ein Label — standardmäßig geschlossen und auch in Realtime beachtet. Durchgesetzt wird es aber von Appwrites Server, es schützt also die Anfragen, die durch diesen Server gehen. Ein Server-API-Schlüssel mit den passenden Scopes umgeht es vollständig, und natives PostgreSQL in der Cloud hat nichts davon.
Was Rebase stattdessen macht
Rebase kompiliert Zugriffsregeln zu Postgres-Row-Level-Security, damit sie gelten, egal auf welchem Weg eine Query ankommt.
- Regeln werden an der Collection in TypeScript deklariert und landen als echte Policies in der Datenbank.
- Eine Tabelle ohne RLS wird gar nicht ausgeliefert, und ein API-Schlüssel umgeht nie eine Policy.
- Realtime-Abonnements werden unter denselben Policies ausgeliefert wie jeder andere Lesezugriff.
Eine Entwicklerkonsole, oder ein Admin-Panel für dein Team
Wo es wehtut
Die Appwrite-Konsole ist ein fähiges Entwicklerwerkzeug: ein Tabelleneditor, CSV-Import und -Export, Logs und seit 2.0 ein API-Explorer und ein Terminal für die CLI. Für die Leute, die das Geschäft betreiben, ist sie nicht gebaut. Es gibt keine eigenen Formulare oder Workflow-Ansichten, nichts, was eine Support-Mitarbeiterin oder ein Redakteur als ihr Werkzeug erkennen würde — dieses Panel bleibt ein Projekt, das du selbst auf dem SDK baust.
Was Rebase stattdessen macht
Rebase erzeugt Rebase CMS, ein React-Admin-Panel, aus derselben Collection-Definition wie die API.
- Tabellen im Spreadsheet-Stil, Formulare und Kanban-Boards, aus dem Schema erzeugt.
- Kann man Kolleginnen ohne technischen Hintergrund geben, weil die Policies in der Datenbank stehen.
- Ersetz jeden Teil davon durch deine eigenen React-Komponenten.
Nicht wechseln
Wann du bei Appwrite bleiben solltest
Wenn deine App in Flutter, Swift oder Kotlin geschrieben ist: Appwrite hat offizielle Client-SDKs für alle drei, und Rebases typisiertes SDK gibt es nur für TypeScript. Wenn du Push-Benachrichtigungen und SMS, Dutzende OAuth-Provider oder Functions in Python, Go oder Dart aus derselben Plattform willst — Appwrite liefert das, Rebase nicht. Und wenn außerhalb des Engineerings niemand das Back-Office öffnet und nichts außer deiner App je die Daten liest, ist eine Datenbank, die du nicht direkt erreichst, kein Preis, den du spüren wirst.
Rebase und Appwrite, beantwortet
Kann ich ein Appwrite-Projekt zu Rebase umziehen?
Ja, aber es ist eine Migration und kein Wechsel der Verbindung, denn Appwrites Datenbank gehört Appwrite, auch wenn sie auf PostgreSQL läuft. Die Zeilen kommen über seine API heraus und gehen in Postgres-Tabellen, die du definierst — meist nahezu eins zu eins, weil TablesDB schon aus Tabellen, Zeilen und Spalten besteht und Relationship-Spalten zu Fremdschlüsseln werden. Nutzer, Storage-Dateien und Functions sind Appwrites eigene Implementierungen; die werden umgezogen oder neu geschrieben, nicht angebunden.
Appwrite läuft jetzt auf PostgreSQL. Was ist noch anders?
Wem die Datenbank gehorcht. Ein selbst gehostetes Appwrite 2.0 nutzt standardmäßig PostgreSQL, aber Appwrite legt das Schema an, prüft Berechtigungen in seinem eigenen Server und stellt die Daten über seine Query-API, REST und GraphQL bereit, nicht über SQL. Das native PostgreSQL von Appwrite Cloud gibt dir SQL — und dafür keine Appwrite-SDKs und keine Plattform-Berechtigungen. Rebase ist beides zugleich: API, typisiertes SDK und Admin-Panel werden auf Tabellen erzeugt, die du auch in psql öffnen kannst, unter derselben Row-Level-Security.
Deckt Rebase die Auth-Funktionen von Appwrite ab?
Die meisten, mit Lücken, die man benennen sollte. Rebase liefert E-Mail und Passwort, Magic Links, Einmalcodes per E-Mail, anonyme Sitzungen, TOTP-Multifaktor, API-Schlüssel mit Geltungsbereich und zwölf OAuth- und OIDC-Provider — oder deinen eigenen Adapter vor Auth0, Clerk oder Firebase Auth. Appwrite hat deutlich mehr OAuth-Provider, Anmeldung per Telefon und SMS sowie E-Mail oder SMS als zweiten Faktor. Eingebautes SAML für deine Endnutzer hat keiner von beiden. Was Rebase dazu beiträgt, ist der Ort, an dem Nutzer leben: eine Tabelle in deinem eigenen Postgres, gegen die Policies und Queries joinen können.
Wann ist Appwrite die bessere Wahl?
Wenn deine App in Flutter, Swift oder Kotlin geschrieben ist: Appwrite hat offizielle Client-SDKs für alle drei, und Rebases typisiertes SDK gibt es nur für TypeScript. Wenn du Push-Benachrichtigungen und SMS, Dutzende OAuth-Provider oder Functions in Python, Go oder Dart aus derselben Plattform willst — Appwrite liefert das, Rebase nicht. Und wenn außerhalb des Engineerings niemand das Back-Office öffnet und nichts außer deiner App je die Daten liest, ist eine Datenbank, die du nicht direkt erreichst, kein Preis, den du spüren wirst.
Hat Rebase Functions, Storage und Messaging wie Appwrite?
Functions und Storage ja, Messaging nur per E-Mail. Rebase hat TypeScript-Functions, die als API-Routen eingehängt werden, Cron-Jobs, Hintergrund-Jobs mit Wiederholungen und Dateispeicher auf der lokalen Platte, jedem S3-kompatiblen Dienst oder Google Cloud Storage. Es verschickt Transaktions-E-Mails über SMTP, hat aber keine Push-Benachrichtigungen und kein SMS, und seine Functions sind nur TypeScript, wo Appwrites in mehr als einem Dutzend Sprachen laufen.
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 Appwrite hält.