Es dauert weniger als fünf Minuten, bis man sich wie ein Software-Zauberer fühlt. Man öffnet einen KI-Code-Generator wie Bolt oder Lovable, gibt einen Prompt ein und sieht zu, wie ein wunderschönes Dashboard erstellt wird, das mit einem Backend verbunden ist. Die UI ist clean, das Dashboard lädt und die ersten Datentabellen werden perfekt gerendert. Die KI teilt Ihnen mit, dass Ihre App über Supabase durch eine relationale Datenbank gestützt wird, und alles scheint bereit für die Produktion zu sein.
Dann deployen Sie die Anwendung, laden Ihre ersten zehn Benutzer ein und sehen zu, wie alles in sich zusammenbricht.
Der Login-Button leitet Benutzer auf eine defekte Seite weiter. Die Datentabellen bleiben komplett leer. Wenn drei Benutzer gleichzeitig klicken, stürzt der Server mit einem Fehler wegen überschrittener Datenbankverbindungslimits ab.
KI-Code-Generatoren sind hervorragend darin, Frontend-Komponenten und clientseitige Datenbankabfragen zu schreiben. Sie können jedoch nicht die Infrastruktur-Richtlinien und Sicherheitseinstellungen konfigurieren, die direkt in Ihrer Datenbankkonsole liegen. Wenn Sie Tools wie v0 oder Replit verwenden, um Ihre Anwendung zu generieren, bleiben Sie der Datenbankadministrator.
Hier sind die vier kritischen Supabase-Konfigurationseinstellungen, die KI-Code-Generatoren nicht automatisieren, und wie Sie diese beheben können, bevor Ihre App live geht.
1. Der blinde Fleck bei der Row-Level Security (RLS)
Postgres verwendet ein Sicherheitsmodell namens Row-Level Security (RLS), um den Zugriff auf einzelne Datenzeilen zu steuern. In Supabase ist RLS für jede neue Tabelle standardmäßig aktiviert. Das bedeutet: Wenn Sie keine explizite Zugriffsrichtlinie schreiben, blockiert Postgres jede einzelne eingehende Anfrage.
Wenn Sie einen KI-Builder bitten, eine neue Datenbanktabelle zu erstellen, generiert dieser oft die SQL-Schema-Definition und führt sie aus. Der Builder kann die Tabellenstruktur sehen und Daten lesen, da er während der Entwicklung den Service-Role-Key verwendet. Sobald Sie jedoch öffentliche clientseitige Abfragen mit dem anonymen Key konfigurieren, gibt die Datenbank leere Arrays zurück.
Die Sicherheitsfalle
Um Dinge schnell zum Laufen zu bringen, schalten einige Builder RLS einfach aus. Das ist ein massives Sicherheitsrisiko. Da Ihre Supabase-Verbindungsdaten im clientseitigen JavaScript-Bundle liegen, kann jeder die Browser-Konsole öffnen, Ihren anonymen API-Key kopieren und Ihre gesamte Datenbank löschen.
So beheben Sie es
Sie müssen explizite SQL-Sicherheitsrichtlinien im Supabase SQL-Editor oder im Dashboard schreiben. Wenn Sie eine Profiltabelle haben, in der Benutzer nur ihre eigenen Daten bearbeiten dürfen, müssen Sie eine Richtlinie erzwingen, die mit ihrer authentifizierten ID übereinstimmt:
create policy "Users can update their own profiles"
on profiles for update
using (auth.uid() = id);KI-Builder können die SQL-Befehle für Sie schreiben, aber sie können sich nicht in Ihre Supabase-Konsole einloggen, um sie auszuführen. Überprüfen Sie immer, ob RLS für jede Tabelle aktiviert ist und ob Sie benutzerdefinierte Richtlinien für das Lesen, Einfügen und Aktualisieren von Daten geschrieben haben.
2. Erschöpfung der Verbindungen in Serverless-Umgebungen
Wenn Sie einen traditionellen Node.js-Server betreiben, öffnet dieser eine einzige persistente Verbindung zu Postgres und teilt diese über verschiedene Anfragen. KI-Code-Generatoren bauen Apps, die in Serverless- oder Edge-Umgebungen wie Cloudflare Pages, Vercel oder Netlify deployed werden.
Jedes Mal, wenn ein Benutzer Ihre App besucht oder einen API-Aufruf auslöst, startet eine Serverless-Funktion, verbindet sich mit Ihrer Datenbank, verarbeitet die Anfrage und schaltet sich wieder aus. Wenn Sie Ihre Anwendung über den direkten Connection-String konfigurieren (normalerweise Port 5432), beansprucht jeder einzelne Funktionsaufruf seine eigene direkte Datenbankverbindung.
Wenn Sie den kostenlosen Tarif von Supabase nutzen, hat Ihre Datenbank ein striktes Limit von 60 gleichzeitigen Verbindungen. Wenn nur zehn Nutzer Ihre App öffnen und einige Dashboard-Charts laden, stoßen Sie sofort an dieses Limit. Ihre Nutzer werden dann Zeitüberschreitungen bei Abfragen und Fehler bei der Datenbankverbindung sehen.
Direkte vs. gepoolte Verbindungen
Sie müssen Ihre Umgebungsvariablen vom direkten Connection-String auf einen gepoolten Connection-String umstellen. Supabase verwendet Supavisor, um Datenbankverbindungen in eine Warteschlange zu stellen und zu verwalten.
- Transaction Pooling (Port 6543): Ideal für Serverless-Anwendungen. Hier werden Verbindungen auf Abfrageebene geöffnet und geschlossen, sodass tausende Nutzer gleichzeitig die Datenbank abfragen können.
- Session Pooling (Port 5432 mit Pooler-Präfix): Hält die Verbindung für die Dauer einer Sitzung aktiv. Dies ist nur notwendig, wenn Sie auf temporäre Postgres-Variablen oder Prepared Statements angewiesen sind.
Ersetzen Sie die Umgebungsvariable für die Datenbank-URL Ihrer Anwendung durch den gepoolten Connection-String, den Sie in den Supabase-Datenbankeinstellungen im Bereich Connection Pooler finden.
3. Auth-Redirect-Loops und SMTP-Fehler
AI-Builder schreiben Authentifizierungscode, der davon ausgeht, dass Ihre App unter http://localhost:3000 oder http://localhost:5173 läuft. Wenn sich ein Nutzer registriert, versendet die App eine Verifizierungs-E-Mail mit einem Redirect-Link, der den Nutzer zurück zu localhost schickt statt an Ihre Live-Produktions-URL.
Die Redirect-Falle
Wenn Ihre Live-Domain mycoolapp.com lautet und ein Nutzer auf einen Bestätigungslink von Supabase Auth klickt, wird er an eine lokale Adresse weitergeleitet, die sein Computer nicht finden kann. Loggt er sich via Google OAuth ein, wird die Anfrage vom OAuth-Provider abgelehnt, da die Redirect-URI nicht mit der Liste der erlaubten Weiterleitungen übereinstimmt.
So beheben Sie das Problem
Sie müssen Ihre Produktions-URLs direkt in der Supabase-Konsole konfigurieren:
- Gehen Sie zu Project Settings > Auth.
- Aktualisieren Sie das Feld Site URL mit Ihrer Produktionsdomain (z. B.
https://mycoolapp.com). - Fügen Sie unter Redirect URLs weitere Callback-Routen hinzu (z. B.
https://mycoolapp.com/auth/callback).
Verlassen Sie sich zudem für Ihre Produktionsnutzer nicht auf den integrierten Supabase-Mailer. Der Standard-SMTP-Server hat ein striktes Limit von drei E-Mails pro Stunde. Sobald eine Handvoll Nutzer versucht, sich zu registrieren, blockiert der Mailer weitere Anmeldungen. Richten Sie einen eigenen SMTP-Anbieter wie Resend oder SendGrid ein und tragen Sie die Zugangsdaten in Ihren Auth-Einstellungen ein.
4. Schema Drift und Migrations-Alpträume
AI-Generatoren funktionieren so, dass sie auf Prompts reagieren und sofort SQL-Statements ausführen, um Ihre Datenbank zu ändern. Wenn Sie die KI anweisen, ein neues Kategorie-Feld zur Produkttabelle hinzuzufügen, führt sie eine ALTER TABLE-Abfrage aus.
Für eine schnelle Validierung funktioniert das gut, aber es umgeht die Versionskontrolle komplett. Wenn Sie eine lokale Entwicklungsumgebung haben, driften Ihr lokales Schema, die Staging-Datenbank und die Produktionsdatenbank auseinander.
Wenn Sie dann versuchen, neue Features zu pushen, haben Sie keine Aufzeichnung über die Datenbankänderungen, die nötig sind, damit der Frontend-Code überhaupt funktioniert.
Die Lösung: Datenbank-Migrationen in Git speichern
Wenn Sie Ihre App langfristig betreiben wollen, lassen Sie die KI die Produktionsdatenbank nicht direkt ändern.
- Nutzen Sie das Supabase CLI, um Datenbank-Schemas lokal zu verwalten.
- Erstellen Sie für jedes Schema-Update Migrationsdateien:
supabase migration new add_category_to_products - Spielen Sie diese Migrationen über eine CI/CD-Pipeline in Ihre Staging- und Produktionsumgebungen ein, anstatt willkürliche SQL-Abfragen per Prompt auszuführen.
So bleibt Ihre Datenbankstruktur in Git dokumentiert und Sie verhindern, dass Sie Code deployen, der auf Spalten referenziert, die in der Produktion gar nicht existieren.
Wann man die Postgres-Management-Gebühr umgeht
Wenn Sie ein SaaS-MVP oder ein komplexes Consumer-Produkt bauen, gehören das Einrichten von Database Poolern und das Schreiben von RLS-Policies einfach zum Job. Aber wenn Ihr Ziel eine operationelle Business-Software ist - wie Kundenportale, interne Dashboards oder Partnerverzeichnisse - müssen Sie diese Infrastruktur-Last nicht zwangsläufig tragen.
Für Business-Tools und Kundenportale können Sie den Verwaltungsaufwand für die Datenbank komplett umgehen, indem Sie Softr nutzen.
Anstatt Sie zu zwingen, Connection-Strings zu konfigurieren, Migrationen zu verwalten oder SQL-Policies zu schreiben, bietet Softr eine native, relationale Datenbank direkt in der Plattform. Sie erhalten visuelle Benutzerberechtigungen, sofortige Suchfilter und sichere Zugriffsregeln, ohne eine einzige Policy schreiben oder einen Postgres-Connection-Pool verwalten zu müssen.
Sie können dem Softr AI Co-Builder einfach Ihren Anwendungsfall beschreiben, und er richtet das Interface, das Datenbank-Schema und die sicheren Zugriffsregeln automatisch ein. Wenn Sie eine Berechtigungsstufe ändern, ein Datenbankfeld hinzufügen oder einen Workflow aktualisieren möchten, erledigen Sie das visuell im Editor. Sie kombinieren die Geschwindigkeit der KI-Generierung mit der Zuverlässigkeit eines wartungsfreien Hostings, sodass Sie sich auf die App-Logik statt auf das Datenbank-Debugging konzentrieren können.