Supabase ist die Falle des Vibe Codings Image: AI generated

Die Magie der 30 Sekunden

„Bau mir ein Backend." Die KI empfiehlt Supabase. Eine einzige URL, und PostgreSQL, Authentifizierung, Storage und Echtzeit-Abonnements sind angeschlossen. Die Anmeldung funktioniert nach 30 Sekunden. Das CRUD ist in 2 Minuten fertig.

Drei Monate später weiß niemand mehr, wer diese RLS-Regeln (Row Level Security) geschrieben hat.

Warum die KI es empfiehlt

Dass Supabase zur Standardwahl beim Vibe Coding geworden ist, liegt nicht an technischer Überlegenheit. Es liegt daran, dass die Trainingsdaten voller Tutorials sind.

Cursor, Bolt, v0, Lovable — egal welches KI-Coding-Tool: Gib „Bau mir ein Backend" ein, und Supabase erscheint. Die KI empfiehlt das Pattern, das sie am häufigsten gesehen hat. Nicht das beste Pattern.

Zhang et al. (ACL 2025) haben empirisch nachgewiesen, dass 7 LLMs ohne explizite Anweisung systematisch bestimmte Anbieter bevorzugen und Eingabecode autonom modifizieren, um den bevorzugten Anbieter einzufügen. Der Benutzer glaubt, dass das, was die KI empfiehlt, optimal ist. Die KI empfiehlt das, was in ihren Trainingsdaten am häufigsten vorkommt. Dies ist die Infrastruktur-Version des Schmeichelei-Bias.

Wenn man Logik in einer Black Box versteckt

Das eigentliche Problem von Supabase ist nicht Supabase selbst. Das Problem ist, dass Geschäftslogik in eine Black Box wandert.

1. RLS-Regeln = versteckte Geschäftslogik

Row Level Security ist eine leistungsstarke Funktion. Das Problem: Wenn die KI RLS-Regeln generiert, wo leben diese?

  • Nicht im Code. Sie befinden sich im Supabase-Dashboard.
  • Nicht in git. Keine Versionskontrolle.
  • Nicht in Tests. Keine Validierung in CI.

Die Antwort auf „Wer kann auf diese Tabelle zugreifen?" existiert nicht im Codebase. Man muss sich in der Supabase-Konsole einloggen, um es zu überprüfen. Ein Agent kann das nicht lesen.

Wenn die KI eine RLS-Regel zum „Aufräumen" ändert? Die Authentifizierung ist kompromittiert. Niemand weiß es, weil es keine Tests gibt. Man entdeckt es erst, nachdem Kundendaten in der Produktion exposiert wurden.

Das ist keine Hypothese. Bei CVE-2025-48757 im Jahr 2025 wurden bei über 170 von Lovable generierten Apps durch fehlende RLS die gesamten Supabase-Datenbanken exposiert. 303 verwundbare Endpunkte, E-Mail-Adressen, API-Schlüssel und Zahlungsinformationen wurden geleakt. Im Januar 2026 wurde das KI-Social-Network Moltbook mit deaktivierten RLS deployed, was 1,5 Millionen API-Token und 35.000 E-Mail-Adressen enthüllte.

2. Edge Functions = zweite Black Box

Geschäftslogik lebt an zwei Orten. Im Frontend-Code und in Supabase Edge Functions. Die KI muss entscheiden, welche Logik wohin gehört. Die KI trifft diese Entscheidung falsch.

Die Rabattberechnung für Zahlungen befindet sich in einer Edge Function. Beim Refactoring des Frontends erstellt die KI dieselbe Berechnung erneut im Frontend. Der Rabatt wird jetzt zweimal angewendet. Drei Wochen später wird es im Umsatzbericht entdeckt.

3. Migration = Ausstiegskosten

Supabase zu verlassen erfordert, vier Dinge gleichzeitig herauszureißen:

  1. Auth — JWT-Struktur gebunden an Supabase Auth, OAuth-Callbacks, Session-Management
  2. Storage — Bucket-Struktur, Zugriffsrichtlinien, URL-Signierung
  3. Realtime — WebSocket-Abonnements, Presence-Kanäle
  4. RLS-Regeln — alle undokumentierten Geschäftsregeln

Jedes Element scheint an einem Tag machbar, aber alle vier sind miteinander verflochten. Ändert man Auth, brechen die RLS; brechen die RLS, öffnet sich der Storage-Zugriff; ändern sich die Storage-URLs, bricht das Frontend.

Das ist vendor lock-in. Der Einstieg dauert 30 Sekunden, der Ausstieg 3 Monate.

Die Cloud-Version der Port-Hölle

Die Port-Hölle, die der Vibe Coder lokal erlebt — die KI startet Server, stoppt sie nicht, Ports geraten durcheinander, man weiß nicht mehr, was läuft — steigt bei Supabase auf die Infrastrukturebene.

Lokale Port-Hölle: Prozesse sind unsichtbar. Supabase-Hölle: Geschäftslogik ist unsichtbar.

Beide haben dieselbe Struktur. Was der Agent erstellt hat, kann der Agent nicht nachverfolgen.

Was ist die Alternative?

Es geht nicht darum, Supabase nicht zu benutzen. Es geht darum, Geschäftslogik nicht in eine Black Box zu stecken.

Grundsatz: Alle Entscheidungen müssen im Codebase leben.

  • Authentifizierungsregeln → im Code deklariert, durch Tests validiert
  • Zugriffsrichtlinien → in DDL + Rego deklariert, in CI verifiziert
  • Geschäftslogik → an einem einzigen Ort, keine Duplikation
  • Infrastrukturkonfiguration → in Terraform/IaC deklariert, in git versioniert

Supabase für das Prototyping zu nutzen ist vernünftig. Aber in dem Moment, in dem ein Prototyp in die Produktion überführt wird, muss die Logik aus der Black Box heraus und in eine deklarative Schicht überführt werden.

Damit die Magie der 30 Sekunden nicht zu 3 Monaten des Leidens wird.

Sind Ihre RLS-Regeln in git?

Haben Ihre Edge Functions Tests?

Sind Sie sicher, dass die Authentifizierung nicht kompromittiert wird, wenn die KI „aufräumt"?

Supabase ist nicht das Problem. Entscheidungen an unsichtbaren Orten zu verstecken, das ist das Problem.

Verwandte Artikel

Quellen

  • Zhang, Y. et al. (2025). “The Invisible Hand: Unveiling Provider Bias in Large Language Models for Code Generation.” ACL 2025. arxiv.org/abs/2501.07849
  • CVE-2025-48757 (2025). Lovable 생성 앱 170+ RLS 누락으로 Supabase DB 노출. ameeba.com
  • OG William (2026). “Moltbook Hack: Supabase Vibe Coding.” 1.5M API 토큰 + 35K 이메일 노출. blog.ogwilliam.com
  • Willison, S. (2025). “Supabase MCP can leak your entire SQL database.” simonwillison.net
  • Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427
  • Storey, M.-A. (2026). “From Technical Debt to Cognitive and Intent Debt.” arxiv.org/abs/2603.22106
  • Encore (2026). “Backend as a Service (BaaS) in 2026: Providers, Tradeoffs, and Migration Paths.” encore.dev