Supabase in Produktion: Was ich vor jedem Go-Live prüfe

Supabase ist der Grund, warum ich manche Projekte überhaupt in wenigen Wochen liefern kann. PostgreSQL, Authentifizierung, Storage, Realtime und eine API stehen am ersten Tag zur Verfügung. Das ist ein enormer Vorsprung.

Genau dieser Vorsprung erzeugt allerdings einen Eindruck, der nicht stimmt: dass der Schritt in den produktiven Betrieb damit auch schon erledigt sei.

Ist er nicht. Supabase nimmt Ihnen die Infrastrukturarbeit ab. Datenmodell, Berechtigungen, Wiederherstellung und der sichere Einsatz in Ihrer konkreten Anwendung bleiben Ihre Aufgabe. Diese Liste ist die, die ich selbst durchgehe, bevor eine Supabase-Anwendung echte Nutzer sieht.

Ist Supabase für produktive Anwendungen geeignet?

Ja. Supabase kann eine belastbare Grundlage für produktive Web- und App-Anwendungen sein. Die Frage ist ohnehin die falsche. Nicht Supabase muss „production ready" sein, sondern Ihr Projekt muss die Sicherheits- und Betriebsfunktionen korrekt nutzen, die Supabase bereitstellt.

Die offizielle Produktions-Checkliste von Supabase nennt dafür unter anderem Row Level Security, den Security Advisor, Lasttests, Backups und eigene SMTP-Zugangsdaten. Die folgenden zehn Bereiche gehen darüber hinaus und decken das ab, was mir in der Praxis am häufigsten begegnet.

1. Row Level Security ist kein optionales Extra

Ich fange immer hier an, und zwar aus einem einfachen Grund: Supabase stellt Ihre Daten über eine automatisch erzeugte API bereit. Wer die Adresse Ihres Projekts kennt, kann diese API direkt ansprechen. Ihr Frontend ist dann nicht mehr im Weg.

Deshalb muss die Berechtigung an der Datenbank durchgesetzt werden, nicht in der Oberfläche. Mit Row Level Security definieren Sie pro Tabelle, welche Datensätze jemand lesen, anlegen, ändern oder löschen darf. Ein ausgeblendeter Button ist keine Autorisierung.

Das sind die Fehler, die ich am häufigsten finde:

RLS ist für einzelne Tabellen gar nicht aktiviert.
Es gibt eine Leseregel, aber keine getrennte Regel für Änderungen.
Ein Nutzer kommt über eine manipulierte Anfrage an Datensätze anderer Mandanten.
Policies vertrauen auf Profildaten, die der Nutzer selbst ändern kann.
Neue Tabellen entstehen im Laufe des Projekts und werden beim Berechtigungskonzept vergessen.

Der letzte Punkt ist der gefährlichste, weil er auch Projekte trifft, die sauber angefangen haben. Testen Sie RLS deshalb nicht einmal, sondern mit jedem neuen Schema-Stand, mit verschiedenen Rollen und mit absichtlich manipulierten Anfragen. Die Supabase-Dokumentation erklärt die Technik. Welches Berechtigungsmodell fachlich richtig ist, kann Ihnen niemand abnehmen.

2. Der service_role-Schlüssel gehört niemals in den Browser

Der öffentliche Schlüssel ist dafür gemacht, im Client zu liegen. Was er kann, begrenzt RLS. Der service_role-Schlüssel umgeht RLS vollständig und gehört deshalb ausschließlich in eine vertrauenswürdige Serverumgebung.

Fünf Fragen, die ich vor dem Go-Live beantwortet haben will:

Welche Schlüssel liegen im Repository, auch in der Historie?
Welche Umgebungsvariablen landen tatsächlich im ausgelieferten Bundle?
Sind Secrets nach Entwicklung, Test und Produktion getrennt?
Lassen sich versehentlich veröffentlichte Schlüssel rotieren, ohne dass die Anwendung stillsteht?
Greifen Server-Funktionen wirklich nur mit den Rechten zu, die sie brauchen?

Ein Geheimnis wird nicht sicherer, weil seine Variable kompliziert benannt wurde.

3. Das Datenmodell braucht fachliche Sicherungen

Validierung im Frontend verbessert die Bedienung. Konsistente Daten garantiert sie nicht. Sobald mehrere Clients, Edge Functions, Importe oder externe Schnittstellen auf dieselben Tabellen schreiben, ist die Datenbank die letzte gemeinsame Grenze.

Geschäftskritische Regeln gehören deshalb zusätzlich nach PostgreSQL:

NOT NULL-Vorgaben
eindeutige Schlüssel
Fremdschlüssel mit durchdachten Löschregeln
Check Constraints
Transaktionen für Änderungen, die zusammengehören

Das kostet beim Bauen ein paar Minuten und erspart Ihnen später die Datenbereinigung, für die es keine gute Stunde gibt.

4. Schemaänderungen müssen reproduzierbar sein

Im Prototyp klicke ich Änderungen auch im Dashboard zusammen. Das ist bequem und für den Moment richtig. Sobald aber ein Team dazukommt oder das System produktiv läuft, muss nachvollziehbar sein, wann Tabellen, Policies, Funktionen und Indizes verändert wurden.

Supabase empfiehlt dafür ein migrationsbasiertes Vorgehen: Änderungen liegen als versionierte SQL-Dateien im Repository, werden lokal geprüft und kontrolliert in die Zielumgebung übertragen.

Ein belastbarer Ablauf beantwortet diese Fragen:

Lässt sich eine komplett neue Umgebung allein aus dem Repository aufbauen?
Sind RLS-Policies und Datenbankfunktionen Teil der Migrationen, nicht nur die Tabellen?
Wird jede Änderung vor Produktion in einer separaten Umgebung geprüft?
Gibt es einen Plan für eine fehlgeschlagene Migration?
Passen die generierten TypeScript-Typen noch zum aktuellen Schema?

Wer sein Datenmodell nur im Dashboard hat, hat einen Zustand. Noch keinen Prozess.

5. Authentifizierung endet nicht beim Login

Der Login funktioniert fast immer. Was seltener getestet wird, sind die Wege daneben:

Registrierung und E-Mail-Bestätigung
Passwort zurücksetzen
Änderung der E-Mail-Adresse
Einladungen und Magic Links
Ablauf und Erneuerung von Sessions
Sperrung und Löschung von Konten
Weiterleitungen nach Auth-E-Mails
Rate Limits und Schutz vor Missbrauch

Richten Sie für produktive Auth-E-Mails eigene SMTP-Zugangsdaten und eine passende Absenderdomain ein. Ein Passwort-Reset, der im Spam landet, ist kein technisches Detail, sondern Ihr erstes Supportticket.

6. Storage braucht ein eigenes Berechtigungskonzept

Dateien wirken harmloser als Datenbankzeilen. In ihnen stecken trotzdem Rechnungen, Verträge, Ausweiskopien und interne Dokumente.

Ist ein Bucket wirklich öffentlich oder nur versehentlich öffentlich?
Wer darf hochladen, lesen und löschen?
Sind Dateityp und maximale Größe begrenzt?
Können Nutzer fremde Pfade erraten oder überschreiben?
Was passiert mit Dateien, wenn der zugehörige Datensatz gelöscht wird?

Storage nutzt ebenfalls Policies. Prüfen Sie sie mit derselben Sorgfalt wie die Regeln Ihrer Anwendungstabellen.

7. Ein Backup ist erst wertvoll, wenn die Wiederherstellung geklärt ist

Je nach Tarif bietet Supabase automatische Backups und optional Point-in-Time Recovery. Prüfen Sie den aktuellen Stand in der offiziellen Dokumentation, die Ausgestaltung ändert sich.

„Backups sind aktiviert" reicht als Antwort aber ohnehin nicht. Klären Sie:

Wie viel Datenverlust wäre im schlimmsten Fall verkraftbar?
Wie lange darf eine Wiederherstellung dauern?
Wer darf sie auslösen, und weiß diese Person, wie es geht?
Sind Dateien und externe Systeme mitgedacht?
Hat den Weg schon einmal jemand tatsächlich durchgespielt?

Backup und Recovery sind zwei verschiedene Aufgaben. Der Haken im Dashboard erledigt nur die erste.

8. Fehler müssen sichtbar werden

Wenn ein Nutzer eine Fehlermeldung sieht, sollten Sie mehr wissen als er. Dafür brauchen Sie mindestens eine zentrale Fehlererfassung, strukturierte Logs für Server- und Edge-Funktionen, eine Alarmierung bei kritischen Fehlern, eine Überwachung Ihrer wichtigsten Geschäftsprozesse und einen Blick auf Datenbankauslastung und langsame Abfragen.

Die Database Advisors von Supabase sind dafür ein guter Startpunkt. Sie erkennen fehlende Indizes und problematische RLS-Konfigurationen. Was sie nicht wissen können, ist, welcher Ihrer Abläufe geschäftskritisch ist.

9. Last und Kosten gehören zum Betrieb

Ein Prototyp erzeugt nie realistische Last. Schätzen Sie deshalb vor dem Launch grob ab, was mit echten Nutzern wächst: Datenbankgröße und Rechenleistung, gleichzeitige Verbindungen, Storage und Datentransfer, Realtime-Verbindungen, Edge-Function-Aufrufe, Auth-E-Mails und externe Dienste.

Es geht nicht darum, jede Skalierungsstufe vorwegzunehmen. Es geht darum, die bekannten Grenzen zu kennen und Kennzahlen zu definieren, bevor jemand sie erreicht.

10. Der Ernstfall braucht einen Namen

Klären Sie vorher, wer erreichbar ist, wenn nachts etwas ausfällt, und was diese Person tun darf. Bei kleinen Projekten sind Sie das selbst. Auch dann hilft es, den Zugang zu Logs, Dashboard und Backups nicht erst im Ernstfall zu suchen.

Kompakte Supabase-Go-Live-Checkliste

Vor der Veröffentlichung sollten Sie diese Fragen beantworten können:

Ist RLS auf allen exponierten Tabellen aktiviert und mit mehreren Rollen getestet?
Sind Rollen und Mandantentrennung fachlich korrekt abgebildet?
Bleiben service_role und alle weiteren Secrets vollständig auf dem Server?
Erzwingt PostgreSQL die wichtigsten Regeln zur Datenintegrität?
Sind Schema, Funktionen und Policies durch Migrationen reproduzierbar?
Funktionieren Registrierung, Passwort-Reset und Auth-E-Mails zuverlässig?
Sind Storage-Buckets und Dateizugriffe korrekt geschützt?
Passt Ihre Backup- und Wiederherstellungsstrategie zum möglichen Schaden?
Werden Fehler, Ausfälle und auffällige Datenbankwerte sichtbar?
Sind Last, technische Limits und laufende Kosten grob eingeordnet?

Nicht jede Anwendung braucht dieselbe Ausbaustufe. Ein internes Werkzeug für zwölf Kollegen hat andere Anforderungen als eine Plattform mit Zahlungen und sensiblen Kundendaten. Die Fragen bleiben dieselben. Die angemessenen Antworten unterscheiden sich erheblich.

Supabase beschleunigt die Entwicklung, nicht die Verantwortung

Supabase spart enorm viel Zeit, und genau deshalb arbeite ich gern damit. Ein schneller Start ist nur eben kein sicherer Betrieb.

Professionell wird eine Supabase-Anwendung in dem Moment, in dem Berechtigungen, Datenmodell, Änderungen und Betrieb nicht mehr zufällig funktionieren, sondern bewusst kontrolliert werden.

Warum das kein reines Supabase-Thema ist, habe ich hier aufgeschrieben: Software bauen war noch nie so einfach. Gute Software bleibt schwierig.

Sie planen den Go-Live einer Supabase-Anwendung oder haben eine bestehende Codebasis übernommen? Schreiben Sie mir kurz über das Kontaktformular oder buchen Sie den Produktionscheck. Ich gehe Security, Datenbank, Deployment und Betrieb mit Ihnen durch und sage Ihnen, was davon vor dem Launch wirklich dran ist.