Warum KI-App-Builder echte Datenbanken statt Mock-Daten brauchen

Kurzantwort

Viele KI-App-Builder generieren eine UI, die mit einer JSON-Datei oder einem Array im Arbeitsspeicher verdrahtet ist, statt mit einer echten Datenbank --- weil das großartig demot und in Minuten shippbar ist. Das Problem zeigt sich später: keine Beziehungen, keine Migrationen, keine Row-Level-Security, keine Möglichkeit, damit umzugehen, dass zwei Personen gleichzeitig schreiben. Von Anfang an auf einem echten, Postgres-gestützten Schema zu bauen kostet fast nichts extra und erspart den kompletten Neubau.

Warum demot ein gefaktes Backend so gut?

Öffne zehn "KI-generierte" App-Builder, tippe in jeden denselben Prompt ein, und mindestens die Hälfte liefert dir in unter einer Minute ein funktionierend aussehendes Dashboard. Klick dich durch, füge eine Zeile hinzu, lade die Seite neu --- sie ist noch da. Sieht gelöst aus.

Schau genauer hin, und diese Zeile lebte die ganze Zeit in einem JavaScript-Array oder einer data.json-Datei, die mit dem Frontend gebündelt ist. Lade aus einem anderen Browser neu, und sie ist weg, weil es nie eine Datenbank gab --- nur ein Skript, das für die Dauer einer Demo eine vorspielte. Das ist keine Kritik an der Idee; ein Mock-Layer ist tatsächlich der schnellste Weg, Pixel auf den Bildschirm zu bringen. Das Problem ist, dass die meisten Builder dir nie sagen, welche Variante du bekommen hast, und Gründer finden es auf die harte Tour heraus --- meist in der Woche, in der sie versuchen, einen zweiten echten Nutzer zu onboarden.

Was verbirgt Mock-Daten eigentlich vor dir?

Hier ist der Teil, der zu selten ausgesprochen wird: Ein Schema ist eine Entscheidung, und Mock-Daten lassen dich diese Entscheidung überspringen. Ein users-Array mit einem favoriteColor-Feld fühlt sich wie ein echtes Datenmodell an. Ist es nicht --- es ist eine Form, keine Struktur. Es gibt keinen Fremdschlüssel, der eine Bestellung mit einem Kunden verknüpft, keine Constraint, die eine doppelte E-Mail-Adresse verhindert, keinen Index, der eine Abfrage schnell hält, sobald du mehr als vierzig Datensätze hast.

Ich habe erlebt, wie Gründer eine App vor Investoren auf Basis eines Mock-Layers demoten, eine Finanzierung bekamen und erst danach einen Entwickler baten, sie "mit einer echten Datenbank zu verbinden" --- als wäre das eine Config-Änderung. Ist es nicht. Es ist ein kompletter Neuentwurf des Datenmodells, weil das Mock nie jemanden gezwungen hat, Fragen zu beantworten wie: Gehört ein Kunde zu einem oder zu mehreren Unternehmen? Was passiert mit seinen Bestellungen, wenn das Unternehmen gelöscht wird? Diese Fragen sind am ersten Tag billig zu beantworten und teuer, nachdem bereits 200 Kundendatensätze gegen die Antwort verstoßen, für die man sich am Ende entscheidet.

Die Schema-Frage wird irgendwann sowieso gestellt

Nur eben von der Produktion statt von dir. Und die Produktion fragt nicht höflich --- sie fragt in Form eines Support-Tickets, eines beschädigten Datensatzes oder eines sehr verwirrten Kunden, dessen Daten verschwunden sind, weil jemand anderes im Team zuerst gespeichert hat.

Was bricht zuerst, wenn du endlich auf eine echte Datenbank umsteigst?

Fast nie die Teile, um die sich Leute Sorgen machen. Es ist selten die SQL-Syntax oder das ORM-Setup. Vier Dinge brechen, ungefähr in dieser Reihenfolge:

Beziehungen. Ein Mock-Array kennt kein Konzept von Fremdschlüsseln, also hat nichts erzwungen, dass jede order.customerId tatsächlich auf einen realen Kunden verweist. Migriere diese Daten nach Postgres, und du findest verwaiste Datensätze, von denen du nicht wusstest, dass es sie gibt.

Migrationen. Mock-Daten haben keine Schema-Version --- du änderst einfach die Array-Form und lädst neu. Eine echte Datenbank braucht jede Änderung als Migration, die sicher gegen bereits existierende Zeilen läuft. Füge einer Tabelle mit 4.000 Live-Zeilen eine NOT NULL-Spalte hinzu, und du brauchst einen Standardwert oder einen Backfill-Schritt, keine Prototyp-Tempo-Änderung.

Row-Level-Security. In einer Demo war "kann Nutzer A die Daten von Nutzer B sehen" nie eine echte Frage, weil es keine Persistenzschicht gab, aus der etwas hätte durchsickern können. Sobald du echte Accounts hast, brauchst du RLS-Policies oder Auth-bewusste Queries, die auf Datenbankebene durchgesetzt werden, nicht nur in der UI versteckt --- denn ein versteckter Button ist keine Sicherheitsgrenze.

Gleichzeitige Schreibvorgänge. Das ist der Punkt, den niemand simuliert, weil man dafür zwei Personen bräuchte, die die App gleichzeitig nutzen, und eine Demo hat genau einen Nutzer: dich. Ein echtes Produkt hat einen Sales Rep und einen Kunden, die denselben Deal in derselben Minute bearbeiten, oder einen Webhook-Retry, der in eine Zeile schreibt, die deine App gerade auch aktualisiert. Ohne Transaktionen und richtiges Locking verschwindet einer dieser Schreibvorgänge einfach lautlos.

Ein echtes Backend von Tag eins vs. später eins draufsetzen

Macht das Überspringen der echten Datenbank die erste Version nicht schneller?

Kaum, und nur für etwa einen Tag. Ein Postgres-Schema mit korrekten Typen, Beziehungen und Auth zu erstellen ist nicht langsamer als eine Mock-JSON-Form zu schreiben, wenn ein Builder beide aus derselben Klartext-Beschreibung generiert --- die Mehrkosten liegen näher an null, als die meisten annehmen, weil die KI die Modellierung ohnehin übernimmt. Teuer ist nicht, auf einem echten Schema zuerst zu bauen. Teuer ist, auf einem gefakten zu bauen und dann doppelt dafür zu bezahlen: einmal für das Mock, und noch einmal für die echte Version, die man am Ende doch braucht.

Das ist das eigentliche Argument dafür, dass Greta Apps von Anfang an gegen Supabase und Prisma generiert statt gegen eine Wegwerf-Schicht. Wenn du ein CRM oder eine Buchungs-App beschreibst, skizziert Greta das Schema, die Beziehungen und die Auth-bewussten Queries von Anfang an als echtes Postgres --- dieselbe App, die du heute demost, ist die, die du morgen skalierst, kein Prototyp, den du still und leise ersetzt. Wenn du das mit Tools für schnelle UI-Mockups vergleichst, deckt Greta vs. Lovable ab, wo diese Grenze in der Praxis sichtbar wird, und die Webhook- und Drittanbieter-API-Seite eines echten Backends lohnt sich zu lesen, sobald du Stripe oder Twilio einbindest.

FAQ

Ist Mock-Daten nicht in Ordnung für einen Prototyp, für den noch niemand bezahlt? Für eine Wegwerf-Pitch-Demo, die du in einer Woche löschst --- klar. Das Problem ist, dass die meisten "Prototypen" still und leise zum Produkt werden, sobald jemand Ja sagt, und niemand den Neubau vorher einplant.

Was ist das erste, was mit Mock-Daten tatsächlich bricht? Meist ein zweiter Nutzer. Eine Person, die ihre eigenen Datensätze bearbeitet, deckt nie fehlende Beziehungen oder Schreibkonflikte auf --- ein zweiter gleichzeitiger Nutzer deckt fast sofort beides auf.

Verlangsamt eine echte Datenbank von Anfang an den Bau eines MVPs? Nicht spürbar, wenn das Tool, das deine App generiert, sowohl UI als auch Schema aus derselben Beschreibung baut. Du verlierst vorne fast nichts und überspringst später einen kompletten Neubau der Datenschicht.

Ist Row-Level-Security für eine kleine App übertrieben? Nicht, wenn sie die Daten von mehr als einer Person speichert. Sobald zwei Accounts existieren, muss etwas durchsetzen, dass Account A nicht die Zeilen von Account B lesen kann --- und ein verstecktes UI-Element zählt nicht.

Fazit

Mock-Daten sind nicht der Feind --- sie sind nur eine Entscheidung, die ein Etikett braucht. Wenn dir ein Tool eine Demo auf einer gefakten Datenschicht baut, ist das in Ordnung, solange du weißt, was du bekommst und was es kostet, sie zu verlassen. Der günstigere Weg ist, gleich mit dem Echten zu starten, denn eine echte Datenbank kostet dich am ersten Tag fast nichts extra und erspart dir am neunzigsten Tag den kompletten Neubau.

Starte noch heute mit dem Bau deiner App mit Greta.