lovable supabase speichert in der Vorschau — live bleibt die Tabelle leer

Dein lovable supabase Setup wirkte in der Vorschau fertig — und auf der Live-URL speicherte nichts, die Liste blieb leer.

In der Vorschau fülltest du ein Formular, sahst die Zeile im Table Editor und nahmst an, Publish verhält sich gleich. Nach dem Deploy sendet die UI weiter. Toasts können Erfolg melden. Im Supabase-Projekt, das du für Produktion hältst, ist die Tabelle leer. Oder Daten landen im Dev-Projekt, während Kunden eine leere Produktions-Datenbank sehen.

Die Fehler gruppieren sich um drei Ursachen: Vorschau und Live sprechen unterschiedliche Supabase-Projekte an, Row Level Security blockiert Inserts ohne Policy, oder Reads treffen das falsche Schema. Der Editor verbindet Supabase beim Bauen — er prüft nicht, ob Hosting-Env-Vars, RLS und Projekt-Ref nach URL-Wechsel noch zusammenpassen.

Speichern in der Vorschau, leer auf der Live-Seite

Das häufigste lovable supabase Symptom: Notiz, Profilfeld oder Bestellzeile in der Vorschau anlegen, Zeile im Dashboard sehen, publishen — dasselbe Formular live sendet ohne klaren Fehler, Liste bleibt blank.

Was du sehen kannst:

• Insert wirkt erfolgreich; Refresh zeigt nichts
• Daten existieren nur in einem Projekt namens dev oder preview
• Network-Tab: 201 Created gegen einen Ref, Live-App liest einen anderen
• SELECT liefert [], weil RLS Zeilen vor der Anon-Rolle versteckt
• Hard Refresh live zeigt leeren State, Lovable-Vorschau noch Daten

Network-Tab auf der Live-Seite öffnen. Requests zu *.supabase.co finden. Projekt-Ref im Hostnamen notieren. Mit dem Ref in der Supabase-Dashboard-URL vergleichen. Weichen sie ab, spricht dein Live-Bundle nicht mit der DB, die du in der Vorschau beobachtet hast.

Auch Keys vergleichen. Lovable injiziert VITE_SUPABASE_URL und VITE_SUPABASE_ANON_KEY für die Vorschau. Produktion liest, was der Host gesetzt hat. Veralteter Anon-Key liefert leere Arrays oder Auth-Fehler, die React hinter optimistischer UI verschluckt.

Warum lovable supabase Vorschau und Produktion auseinanderlaufen

Lovable erzeugt den Supabase-Client gegen die sichtbare Umgebung — Vorschau-Origin und Keys aus der Editor-Integration. Publish kopiert das Frontend zu Vercel, Netlify oder Custom Domain. Der Host-Build bundelt mit Production-Env-Vars. Hast du URL und Anon-Key nie zum Host kopiert, embeddet der Build Leerstrings, Platzhalter oder Keys aus einem alten Experiment.

KI-Assistenten legen schnell frische Supabase-Projekte an. Eine Session verknüpft Projekt A, eine spätere Projekt B nach Reset. Vorschau nimmt die neueste Integration. Produktion zeigt noch auf A, bis du Hosting-Secrets manuell aktualisierst.

Weiteres Muster: Vorschau nutzt Service Role serverseitig, Live den Anon-Key im Browser. Service Role umgeht RLS — Daten in der Vorschau. Live-Anon trifft RLS und liefert nichts. Fix sind Policies, nicht noch ein Prompt im Chat.

Fehlende INSERT-Policy blockiert Live-Saves

RLS aktiviert — gut. Inserts scheitern mit new row violates row-level security policy oder still, wenn der Client Postgres-Fehler nicht anzeigt. Vorschau kann noch laufen, wenn RLS im Dev-Projekt aus war oder Preview eine bypassende Rolle nutzte.

RLS defaultet auf deny. Pro Operation brauchst du explizite Policies. SELECT allein erlaubt Lesen, nicht Anlegen. INSERT braucht with check, der neue Zeilen an auth.uid() bindet.

Typischer Fix für nutzereigene Zeilen:

alter table public.items enable row level security;

create policy "Users read own items"
on public.items for select
using (auth.uid() = user_id);

create policy "Users insert own items"
on public.items for insert
with check (auth.uid() = user_id);

Häufige Fehler nach RLS in einer lovable supabase App:

• INSERT-Policy fehlt komplett
• user_id beim Insert nicht gesetzt — Policy-Check scheitert
• Policy nutzt auth.uid(), Client insertet ausgeloggt
• Nur authenticated erlaubt; Anon-Tests scheitern erwartbar
• Policies nur im Dashboard, nie in Migrationen — Redeploy from scratch löscht sie

Als echter eingeloggter Nutzer auf der Live-URL testen, nicht nur im Table Editor mit Admin-Zugang. Vollbild zu Absicherung: supabase rls.

Zwei verschiedene Supabase-Projekte

Split-Brain entsteht leicht, wenn einer Supabase in Lovable verbindet und ein anderer Env-Vars aus einem alten Screenshot nach Vercel kopiert. Vorschau schreibt in abcd1234, Produktion liest wxyz9876. Jedes Dashboard wirkt gesund. Die App zeigt nie vereinheitlichte Daten.

Audit in vier Schritten:

1. Lovable-Projekteinstellungen — Supabase-URL und Anon-Key der Vorschau notieren.
2. Hosting → Environment Variables → Production — URL und Key Zeichen für Zeichen vergleichen.
3. Live-Seite, DevTools → Network, Save auslösen, *.supabase.co-Hostname lesen.
4. Supabase → Project Settings → General — Ref muss in allen drei Quellen passen.

Weicht etwas ab: ein Produktionsprojekt wählen, alles angleichen, Host-Env aktualisieren, redeployen. Zeilen aus dem falschen Projekt migrieren oder akzeptieren, dass Vorschau-Testdaten nie Produktionsdaten waren.

lovable supabase vor dem nächsten Deploy fixen

1. Einen Supabase-Projekt-Ref über Lovable-Vorschau, Hosting-Production-Env und Live-Network-Requests bestätigen.
2. VITE_SUPABASE_URL und VITE_SUPABASE_ANON_KEY in Production-Env kopieren. Nach Änderungen redeployen.
3. Jede Tabelle inventarisieren, die die App liest oder schreibt. RLS auf Tabellen mit Nutzer- oder Privatdaten.
4. SELECT-, INSERT-, UPDATE- und DELETE-Policies passend zum App-Verhalten.
5. Inserts setzen user_id (oder Äquivalent) vor Policy-Lauf.
6. Ausgeloggt auf Live, REST mit Anon-Key — private Zeilen nicht listbar.
7. Eingeloggt auf Live, Zeile speichern — im richtigen Projekt im Table Editor sichtbar.

Policy-SQL in Migrationen versionieren. Dashboard-only klickt zwischen Staging und Produktion auseinander wie Env-Vars.

DB-Wiring ist eine von fünf Production-Einstellungen, die KI-Editoren selten abfragen. Auth-URLs, Stripe-Webhooks, Env-Vars und TLS scheitern am selben Launch-Wochenende. Die lovable deploy Checkliste deckt den Rest ab.

Checkliste vor Launch

• Gleicher Supabase-Projekt-Ref in Vorschau, Production-Env und Live-Traffic
• Production Anon-Key und URL nach Projekt-Rotation redeployt
• RLS auf jeder Tabelle, die nicht weltlesbar sein soll
• INSERT-Policy für jede Tabelle, in die Nutzer live speichern
• user_id beim Insert vor Policy-Evaluation gesetzt
• Ausgeloggt können Anon-Requests private Zeilen nicht lesen
• Policies in Migrationen, nicht nur manuelle Dashboard-Edits

Vorschau-Daten sind keine Produktionsdaten, bis dasselbe Projekt, dieselben Keys und Policies beide URLs bedienen.

FAQ

Warum funktioniert lovable supabase in der Vorschau, live aber leer?

Vorschau und Produktion nutzen oft unterschiedliche Supabase-URLs oder Anon-Keys. Live kann auch Tabellen mit RLS ohne INSERT-Policy treffen — Schreiben scheitert, UI wirkt normal.

Wie prüfe ich, dass Lovable und Produktion dasselbe Supabase-Projekt nutzen?

Vergleiche VITE_SUPABASE_URL und VITE_SUPABASE_ANON_KEY in Lovable-Vorschau mit den Production-Env-Vars beim Host. Der Projekt-Ref in der URL muss auf beiden Seiten identisch sein.

Brauche ich RLS-Policies für lovable supabase Apps?

Ja, für Tabellen mit Nutzerdaten. RLS aktivieren und SELECT- sowie INSERT-Policies mit auth.uid() setzen. Ohne INSERT-Policy schlagen authentifizierte Saves fehl, obwohl die Vorschau offen wirkte.