Rebase
vs
Supabase

Rebase gegen Supabase

Beide legen Row-Level Security in Postgres ab. Der Unterschied ist, wo die Policy geschrieben wird: Bei Supabase lebt sie in der Datenbank und du hältst sie von Hand mit deinem Code synchron; bei Rebase ist sie ein Feld an der Collection, das zu einer Policy kompiliert wird, und dieselbe Datei generiert die API, das typisierte SDK und das Admin-Panel.

Sicherheit & RBAC

RLS ohne die Fußangel

Wo es wehtut

Beide Projekte legen Autorisierung in Postgres-Row-Level-Security ab, und Supabase Studio hat einen Policy-Editor mit Generator und Vorlagen dahinter. Der Unterschied ist, wo die Policy danach lebt: Bei Supabase ist sie ein Datenbankobjekt, das du von Hand mit deinem Code im Gleichschritt hältst, bei Rebase ein Feld an der Collection, das zu einer Policy kompiliert — Policy, API und Panel bewegen sich gemeinsam, und Drift zwischen Code und Datenbank meldet der Editor.

Was Rebase stattdessen macht

Rebase schreibt die Policy dorthin, wo die Collection steht. Statt eines separaten SQL-Objekts deklarierst du die Regel in TypeScript, und der Compiler macht daraus eine echte Postgres-Policy.

  • Ein visueller Policy-Editor, der die Datenbank zurückliest und Drift meldet.
  • Der Kontext der Regel ist TypeScript statt eines handgeschriebenen JOINs.
  • Pro Collection, pro Feld und pro Rolle, in der Datei, in der die Collection lebt.
Infrastruktur

Self-Hosting, symmetrisch

Wo es wehtut

Supabase selbst zu hosten ist ein unterstützter Weg mit veröffentlichter Docker-Compose-Datei, und viele Teams tun es. Was du übernimmst, sind mehrere Dienste in mehreren Sprachen — PostgREST in Haskell, Auth in Go, Realtime in Elixir, Edge Functions auf Deno — jeder mit eigenem Release-Takt. Rebase ist ein Node-Prozess und ein Postgres: weniger aktuell zu halten, nicht kategorisch etwas anderes.

Was Rebase stattdessen macht

Rebase ist ein einziges Node.js-Backend auf Standard-Hono und Drizzle ORM.

  • Ein Dienst zum Deployen: Docker, Railway, Fly oder Bare Metal.
  • Durchgehend TypeScript — die Sprache, die dein Team ohnehin liest.
  • Keine undurchsichtigen Binaries zwischen dir und der Datenbank.
Architektur

Schema als Code

Wo es wehtut

Bei Supabase ist die Datenbank der Zustand. Lokal, Staging und Produktion laufen auseinander, wenn niemand sie im Gleichschritt hält, und RPCs, Trigger und RLS als rohe SQL-Dateien zu versionieren verlangt eine Disziplin, die freitags niemand hat.

Was Rebase stattdessen macht

Bei Rebase ist die Schema-Definition eine eigenständige TypeScript-Datei — config/collections/products.ts — und Git ist die Quelle der Wahrheit.

  • Rebase Studio nutzt AST-Manipulation, um Felder sicher in deinen Code einzufügen.
  • Drizzle-Migrationen werden aus derselben Definition erzeugt und angewendet.
  • Der Code ist die Quelle der Wahrheit, also stimmen die Umgebungen von selbst überein.

Nicht wechseln

Wann du bei Supabase bleiben solltest

Wenn du das größte Ökosystem dieser Kategorie willst, die meisten Tutorials von Dritten oder Edge Functions am CDN. Supabase ist das reifere Produkt mit einer viel größeren Community — und wenn außerhalb deines Engineering-Teams nie jemand das Back-Office öffnet, ist das meiste, was Rebase hinzufügt, Gewicht, das du nicht nutzt.

Fragen

Rebase und Supabase, beantwortet

Kann ich Rebase mit meiner bestehenden Supabase-Datenbank nutzen?

Ja. Rebase verbindet sich mit jeder PostgreSQL-Datenbank, auch der hinter einem Supabase-Projekt, und liest die Tabellen, die schon da sind, statt eine eigene Form zu verlangen. Was nicht mitkommt, ist der Teil von Supabase, der kein Postgres ist: ihr Auth-Schema, ihre Edge Functions und ihre Storage-Buckets sind ihre Implementierungen — die würdest du ersetzen, nicht importieren.

Wenn beide Postgres mit Row-Level Security sind, was ist dann tatsächlich anders?

Woher die Policies kommen. Bei Supabase schreibst du RLS als SQL in einem Dashboard, und eine Policy, die still null Zeilen zurückgibt, ist eine Debug-Sitzung ohne Stacktrace. Bei Rebase ist die Policy Teil der Collection-Definition in TypeScript und kompiliert bei der Migration zu einer echten Postgres-Policy. Die Durchsetzung ist identisch — es ist beide Male Postgres — aber die Regel lebt in deinem Repository, geht durch Code-Review und taucht in einem Diff auf.

Ist das Supabase-Dashboard nicht schon ein Admin-Panel?

Es ist ein Tabelleneditor, und das ist ein anderes Produkt. Er ist für Entwickler gebaut: rohe Zeilen, Fremdschlüssel-UUIDs, kein Workflow, keine Rollen jenseits von Datenbankrollen. Rebase erzeugt eine Oberfläche für die Menschen, die das Geschäft führen — Formulare, Medien, Berechtigungen, Kanban-Boards und deine eigenen React-Komponenten überall dort, wo das Generierte falsch ist — aus denselben Collection-Definitionen, die die API erzeugt haben.

Wann ist Supabase die bessere Wahl?

Wenn du das größte Ökosystem der Kategorie willst, die meisten Tutorials von Dritten oder Edge Functions am CDN. Supabase ist das reifere Produkt mit einer viel größeren Community — und wenn außerhalb deines Engineering-Teams nie jemand das Back-Office öffnet, ist das meiste, was Rebase hinzufügt, ungenutztes Gewicht.

Wie viel Umschreiben bedeutet ein Umzug von Supabase zu Rebase?

Die Datenbank ist der Teil, der sich nicht ändert — es ist auf beiden Seiten Postgres. Was sich ändert, ist der Client: Supabases JS-Client und Rebases typisiertes SDK sind verschiedene APIs, Aufrufe müssen also umgeschrieben werden, und jede im Dashboard geschriebene Policy muss als Access-Rule einer Collection ausgedrückt werden. Realistisch ist das eine Migration der Client-Schicht, keine Datenmigration.

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 Supabase hält.

~pnpm dlx @rebasepro/cli init