Supabase in Entwicklung und Betrieb
Supabase ist eine Plattform um PostgreSQL herum: Datenbank, Authentifizierung, Dateiablage und serverseitige Funktionen in einem Paket. Wir setzen sie als Standard-Backend für Individualsoftware ein — entweder als verwaltete Instanz in einer EU-Region oder vollständig selbst gehostet auf Servern, die dem Kunden gehören. Der Unterschied liegt im Betrieb, nicht im Code.
Was wir davon einsetzen
Supabase bringt mehrere Dienste mit. Genutzt wird, was die Anwendung braucht — nicht alles, weil es dabei ist.
PostgreSQL
Der eigentliche Grund für die Wahl. Relationale Daten gehören in eine relationale Datenbank, und Postgres wird es in zehn Jahren noch geben. Schema, Fremdschlüssel und Constraints bilden die Fachlogik ab, statt sie in die Anwendung zu verlagern — was die Datenbank erzwingt, kann kein Client umgehen.
Row Level Security
Zugriffsrechte liegen als Policy an der Tabelle, nicht in der Anwendung. Wer welche Zeile sieht, entscheidet die Datenbank. Das ist der Unterschied zwischen einer vergessenen Prüfung im Code und einer Regel, die auch ein direkter Zugriff nicht aushebelt. Jede Tabelle mit Kundendaten bekommt RLS, bevor sie Daten enthält.
Auth
Anmeldung mit E-Mail, OAuth-Anbietern oder SSO, dazu rollenbasierte Rechte über Claims im Token. Die Rolle steht im JWT, die Policy liest sie — so hängen Anmeldung und Berechtigung an derselben Stelle zusammen.
Storage
Dateiablage für Belege, Fotos und Dokumente, mit denselben RLS-Policies wie die Tabellen. Ein Dokument, das die Datenbank nicht herausgeben würde, gibt auch die Ablage nicht heraus.
Edge Functions
Serverseitige Funktionen für alles, was nicht in den Client gehört: Zahlungen, Webhooks, Zugriff auf fremde Schnittstellen mit Schlüsseln, die niemand im Browser sehen darf.
Realtime
Änderungen an Tabellen erreichen offene Clients ohne Nachfragen. Wir setzen es dort ein, wo mehrere Personen gleichzeitig an denselben Daten arbeiten — nicht überall, weil eine offene Verbindung auch Kosten hat.
Wie ein Projekt bei uns aufgesetzt ist
Sechs Festlegungen, die am Anfang getroffen werden und über die gesamte Laufzeit gelten. Sie sind der Grund, warum ein Projekt zwei Jahre später noch änderbar ist.
Das Schema liegt in der Versionskontrolle
Jede Änderung an der Datenbank ist eine Migrationsdatei im Repository, angelegt über die Supabase-CLI. Niemand klickt eine Spalte im Dashboard zusammen. Dadurch lässt sich jede Umgebung aus dem Repository neu aufbauen, und man sieht im Verlauf, wann welche Spalte warum dazukam.
Drei Umgebungen, gleiche Migrationen
Lokal über die Supabase-CLI in Docker, dazu eine Testumgebung und der Betrieb. Alle drei bekommen dieselben Migrationen in derselben Reihenfolge. Eine Änderung, die auf der Testumgebung nicht durchläuft, erreicht den Betrieb nicht.
RLS-Policies sind Teil der Migration
Policies werden mit der Tabelle angelegt, nicht danach. Eine Tabelle ohne aktivierte RLS gilt bei uns als Fehler, nicht als offener Punkt — auch dann, wenn zunächst nur Testdaten darin stehen.
Typen kommen aus dem Schema
Die TypeScript-Typen werden aus der Datenbank erzeugt, nicht parallel gepflegt. Wer eine Spalte umbenennt, bekommt den Fehler beim Übersetzen und nicht im Betrieb.
Schlüssel bleiben serverseitig
Im Browser liegt ausschließlich der anonyme Schlüssel, dessen Rechte vollständig über RLS begrenzt sind. Der Service-Role-Schlüssel umgeht RLS und liegt deshalb nur in Edge Functions und serverseitigen Umgebungsvariablen — nie in einer Client-Anwendung, nie im Repository.
Auslieferung ist zurückrollbar
Anwendung und Datenbankstand gehören zusammen. Migrationen werden additiv geschrieben, damit die vorherige Anwendungsversion mit dem neuen Schema noch läuft — das ist der Unterschied zwischen einem Fehler und einem Ausfall.
Wo Ihre Daten liegen
Zwei Wege, dieselbe Anwendung. Die Entscheidung fällt vor dem Projektstart, weil sie sich später nur mit Aufwand umkehren lässt.
Verwaltete Instanz in einer EU-Region
Der übliche Weg. Supabase betreibt die Instanz, wir betreuen Schema, Policies und Anwendung. Für die Verarbeitung personenbezogener Daten braucht es einen Auftragsverarbeitungsvertrag mit dem Anbieter — den schließen wir vor dem ersten Echtdatensatz ab, nicht danach.
- Region beim Anlegen auf die EU festgelegt, nachträglich geht das nicht
- Point-in-Time-Recovery, wo der Tarif es hergibt
- Auftragsverarbeitungsvertrag liegt vor Inbetriebnahme vor
Selbst gehostet auf Ihren Servern
Supabase ist quelloffen und lässt sich vollständig selbst betreiben. Wir setzen es auf Ubuntu mit Docker Compose auf, davor Nginx als Reverse Proxy mit automatisch erneuerten Zertifikaten. Sinnvoll, wenn Auflagen oder eine bestehende Serverlandschaft es verlangen — nicht als Grundeinstellung, weil der Betrieb dann bei Ihnen oder bei uns liegt und nicht beim Anbieter.
- Ubuntu, Docker Compose, Nginx, automatisierte Zertifikate
- Aktualisierungen und Überwachung übernehmen wir im Wartungsvertrag
- Läuft auch im eigenen Rechenzentrum ohne Verbindung nach außen
Backup und Wiederherstellung
Wir verkaufen Backup-Konzepte. Die eigenen müssen deshalb sitzen — und ein Backup, das nie zurückgespielt wurde, ist eine Vermutung, kein Backup.
- Sicherung nach dem 3-2-1-Prinzip: drei Kopien, zwei Medien, eine außer Haus
- Zusätzlich zum Anbieter-Backup ein eigener Auszug, der nicht im selben Konto liegt
- Dokumentierter Wiederherstellungstest in eine leere Umgebung, nicht nur ein Kopiervorgang
- Wiederherstellungszeit und maximaler Datenverlust werden pro Projekt festgelegt, nicht angenommen
Im eigenen Produktivbetrieb
Der Beleg ist kein Beispielprojekt, sondern unser eigenes Produkt im Produktivbetrieb: Rentavo, eine Plattform für die Immobilienverwaltung. Wir haben sie konzipiert, gebaut und betreiben sie selbst — Migrationen, Sicherungen und Störungen sind unsere.
- Drei Clients, ein Regelwerk: Die App für iOS, die App für Android und das Web-Portal sprechen mit derselben Datenbank. Wer welche Zeile sieht, entscheidet einmal die RLS-Policy — nicht dreimal die jeweilige Anwendung.
- Anmeldung und Rechte laufen für alle drei über dieselbe Authentifizierung. Eine Rolle wird an einer Stelle vergeben und gilt überall.
- Das Schema liegt vollständig in Migrationen. Was auf dieser Seite über Arbeitsweise steht, ist an Rentavo entstanden und nicht daneben aufgeschrieben worden.
- Öffentlich prüfbar, ohne NDA: Es ist unser eigenes Produkt, kein Kundenprojekt. Deshalb dürfen wir hier über Architektur und Betrieb überhaupt reden.
Offener Inhalt: {{TODO: Betriebsform der Supabase-Instanz von Rentavo bestätigen — verwaltete Instanz in einer EU-Region oder selbst gehostet? Der Satz gehört in den Beleg-Abschnitt auf /technologie/supabase/, weil dort beide Wege angeboten werden. Vor dem Absenden der Supabase-Bewerbung klären.}}
Was wir damit nicht machen
Vier Festlegungen gegen Bequemlichkeiten, die sich später rächen.
- Keine Fachlogik in der Datenbank, die niemand mehr lesen kann. Constraints und Policies ja, ganze Abläufe in Triggern nein — sie sind schwer zu testen und noch schwerer zu übergeben.
- Kein Realtime, wo ein normaler Abruf reicht. Eine offene Verbindung je Nutzer kostet Geld und Aufmerksamkeit im Betrieb.
- Kein Direktzugriff aus dem Browser auf Tabellen ohne RLS. Auch nicht in einem Prototyp — Prototypen werden erfahrungsgemäß produktiv.
- Kein Supabase, wo eine Datei genügt. Bei Werkzeugen ohne Nutzerkonten und ohne gemeinsame Daten wäre eine Datenbank Aufwand ohne Gegenwert.
Häufige Fragen
Was an dieser Stelle regelmäßig gefragt wird — meist von der Person, die den Stack am Ende beurteilen muss.
Liegen unsere Daten dann in den USA?
Nein, sofern die Instanz in einer EU-Region angelegt wird — das legen wir beim Anlegen fest, und es lässt sich nachträglich nicht ändern. Wer darüber hinaus sichergehen will oder muss, bekommt eine selbst gehostete Installation auf Servern in Deutschland oder im eigenen Haus.
Für beide Wege gilt dasselbe: Vor dem ersten echten Datensatz steht der Auftragsverarbeitungsvertrag. Bei einer selbst gehosteten Installation entfällt der Anbieter als Auftragsverarbeiter, dafür übernehmen wir oder Sie den Betrieb.
Was passiert, wenn wir den Anbieter später wechseln wollen?
Darunter liegt eine gewöhnliche PostgreSQL-Datenbank. Ein vollständiger Auszug lässt sich in jede andere Postgres-Installation einspielen, auch in eine selbst betriebene. Gebunden sind Sie an die Zusatzdienste — Authentifizierung, Dateiablage, Edge Functions —, nicht an die Daten.
Genau deshalb halten wir Fachlogik in der Anwendung und nicht in anbieterspezifischen Bausteinen. Ein Wechsel ist damit Arbeit, aber kein Neubau.
Bekommen wir Zugriff auf alles?
Ja. Quellcode, Migrationen, Dokumentation und die Anleitung zum Deployment gehen vollständig an Sie über. Die Zugänge zur Datenbank gehören Ihnen, nicht uns.
Das ist kein Entgegenkommen, sondern die Bedingung dafür, dass Sie uns jederzeit ersetzen können. Ein Dienstleister, den man nicht wechseln kann, ist ein Risiko.
Nutzt ihr Supabase auch für diese Website?
Diese Website ist statisch erzeugt und braucht zur Auslieferung keine Datenbank. Vorgesehen ist Supabase hier für die Persistenz der Formularanfragen — Anfragen dürfen nicht nur per E-Mail laufen, weil sie sonst in Spam-Filtern verloren gehen.
Bis das umgesetzt ist, steht es hier als offener Punkt und nicht als erledigte Zusage.
Reden wir 20 Minuten
Erzählen Sie, was gerade klemmt. Wir sagen Ihnen ehrlich, ob wir passen — und wenn nicht, woran es liegt. Kein Verkaufsgespräch, keine Kosten.
Wir antworten innerhalb von 24 Stunden — 7 Tage die Woche, auch an Feiertagen.
Direkter Weg
- info@rentavo-services.de
- Telefon
Offener Inhalt: {{TODO: Telefonnummer}}
- Anschrift
- Johannisstraße 29
26121 Oldenburg - Servicezeit
- Servicezeit für Bestandskunden: {{TODO: Servicezeit, z. B. Mo–Fr 8–17 Uhr}}