Adorable vs. Lovable, v0, Bolt und Replit: wo dein Backend wirklich läuft

Generierung ist gelöst. Lovable, v0, Bolt, Replit und Adorable machen alle aus einem Absatz eine laufende App mit Datenbank dahinter. Wenn dein Vergleich bei „kann es aus einem Prompt eine CRUD-App bauen" aufhört, bestehen alle Tools und die Frage ist Geschmackssache.

Also hör auf, die Demo zu vergleichen. Drei architektonische Fragen unterscheiden diese Produkte wirklich, und keine davon taucht auf einer Preisseite auf:

1. Wo läuft dein Backend-Code physisch? 2. Was macht ein Deploy mit deinen Daten — und kannst du es rückgängig machen? 3. Wie viele bewegliche Teile darf dein Backend haben — und wer verdrahtet sie?

Alles Folgende wird an diesen drei Achsen gemessen, Stand Juni 2026. Wir werden konkret sagen, wo die anderen wirklich stark sind, denn die ehrliche Version ist nützlicher als die schmeichelhafte.

Achse 1: wo das Backend läuft

In dieser Kategorie gibt es genau drei Antworten, und sie haben sehr unterschiedliche Konsequenzen.

Serverless-Funktionen — Lovable, v0, Bolt (in Produktion). Dein „Backend" ist ein Bündel zustandsloser Handler. Lovable führt sie als Supabase Edge Functions (Deno) aus; v0 führt Next.js Route Handler und Server Actions als Vercel Functions aus; Bolts Produktionsziel führt sie auf Bolt Cloud oder Netlify aus. Es gibt keinen persistenten Prozess. Jeder Request weckt ein Isolate, läuft und stirbt.

Dieses Modell ist exzellent für Request/Response-CRUD und wirklich schwierig für alles Zustandsbehaftete: ein langlebiges WebSocket, eine In-Process-Job-Queue, ein warmer Cache, ein Worker, der einen Backlog abarbeitet, ein Task, der zwei Minuten läuft. Keines davon hat einen Prozess, in dem es leben kann. Du bekommst sie nur zurück, indem du weitere Managed Services dranschraubst (eine separate Queue, einen separaten Realtime-Server, ein Cron-Produkt).

Der Browser — Bolt (in Entwicklung). Bolts Dev-Runtime ist ein WebContainer: Node nach WASM kompiliert, das dein Backend im Browser-Tab ausführt, während du editierst. Es ist eine schnelle, clevere Dev-Schleife. Es ist aber nicht der Ort, an dem die App lebt — Persistenz und Produktion gehen weiterhin an Bolt Cloud / Supabase / Netlify über. Das, was du editierst, und das, was die Nutzer bedient, sind zwei verschiedene Runtimes.

Ein echter Container — Replit und Adorable. Replit führt dein Backend als echten langlaufenden Prozess in einem Linux-Container aus, und wir auch. Das ist das einzige Modell, in dem ein normaler Server normal ist: Verbindungen halten, Hintergrund-Worker in-process laufen lassen, Zustand zwischen Requests behalten.

Adorables Form: jedes Projekt ist sein eigener Kubernetes-Namespace mit einem echten App-Pod — Vite + ein tRPC/Express-Server — gegen ein echtes Postgres. Kein Funktionsbündel; ein Prozess. Wenn es idle ist, friert das Ganze ein (cgroup v2 Freezer, Swap zurückgewonnen) und das Postgres-Compute skaliert auf null, sodass „ein echter Server" nicht „ein Server, für den du rund um die Uhr zahlst" bedeutet. Es bedeutet, der Server existiert, hält Zustand und kostet nichts, während niemand hinschaut.

Die praktische Linie: drei der fünf führen kein Backend aus, sie führen Funktionen aus. Wenn deine App Formulare über Daten ist, ist das in Ordnung. Hat sie einen Worker, ein Socket oder einen langen Task, zwingt dich das Funktionsmodell, sie aus Teilen zusammenzusetzen; das Container-Modell führt sie einfach aus.

Achse 2: was ein Deploy mit deinen Daten macht

Das ist die Achse, die die „Prod vs. Preview Environment"-Checkboxen verschleiern.

Für einen Serverless-Builder bedeutet „Deploy": ein neues Funktionsbündel veröffentlichen und es auf eine Datenbank zeigen lassen, die du verbunden hast. Der Code ist versioniert (es ist git); die Daten sind eine einzige Live-Datenbank, in die jeder Deploy direkt durchschreibt. Die Branche hat begonnen, über die Lücke hinwegzukleistern:

• Lovable macht ein tägliches Backup der Projektdatenbank (laut Docs rund 14 Tage Aufbewahrung). Das ist ein echter Wiederherstellungspunkt — aber es ist ein täglicher Snapshot, von dem aus du vorwärtsrollst, kein Branch, von dem du die gesamte Umgebung zu einem beliebigen point-in-time forken kannst.
• v0 hat Daten tatsächlich schwerer gemacht: es verbindet sich mit einer Datenbank, die du bereits betreibst (AWS- oder Snowflake-Datenbanken oder ein Marketplace-Anbieter) — es gibt keinen „Datenbank erstellen"-Button. Die Datenschicht gehört dir: provisionieren, migrieren und schützen.
• Replit verlangt eine separate Produktionsdatenbank für Deploys — echte Isolation zwischen dev und prod, von den vieren das Nächste an unserem Modell, und läuft jetzt auf Replits eigener Datenbank-Infrastruktur statt bei einem Drittanbieter. Aber ein Deploy ist immer noch „Code ausliefern, Migrationen gegen Prod fahren" — mit demselben einbahnigen Datenrisiko, das jede Migration trägt.

Adorable behandelt das anders, weil die Datenbank eine Copy-on-Write-Postgres- Timeline ist (selbst gehostetes Neon), kein Server, den du dumpst und wiederherstellst:

• Produktion ist ein dauerhafter Branch. Der erste Deploy forkt dev in eine Prod-Timeline mit eigenen Daten. Re-Deploys behalten diese Timeline — die Prod-Daten echter Nutzer überdauern Releases. Live-Gehen bewegt kein Byte; es ist eine Branch-Promotion, keine Migration.
• Jedes Release pinnt einen git-Commit und taggt einen Pre-Deploy-LSN-Checkpoint auf Prods Head, bevor ausstehende Migrationen angewendet werden. Dieser Checkpoint ist ein verpflichtender Rollback-Anker, kein optionales Backup.
• Ein Rollback stellt Code und Daten wieder her. Rolle zurück auf Release N, und du bekommst N's gepinnten Commit neu deployt und den Prod-Daten-Fork-from-Checkpoint aus N's Ära. Git gibt jedem Tool bereits ein Code-Undo. Nichts anderes hier gibt dir ein Daten-Undo, das an denselben Moment gebunden ist.
• Der Agent snapshottet sich selbst vor riskanten Operationen. Vor einer destruktiven Migration oder einer Massenänderung setzt er einen Checkpoint; bricht die Operation die Daten, rollt er zurück — Copy-on-Write, also ändert sich der Connection String nie.

Der letzte Punkt ist der ohne Entsprechung bei irgendeinem der vier. Ein AI-Agent wird irgendwann DROP COLUMN auf der falschen Spalte ausführen. Git rettet dich nicht, denn git versioniert Code, keine Rows. Ein tägliches Backup hilft nur, wenn du es vor dem nächsten Snapshot bemerkst, und es stellt die ganze Datenbank wieder her, nicht die eine Tabelle. Code-und-Daten-Time-Travel rückt den Fehler bis auf einen point-in-time Fork an das Ungeschehene heran.

Achse 3: wie viele bewegliche Teile darf dein Backend haben?

Das Funktionen-plus-eine-Datenbank-Modell nimmt an, dass dein Backend eine App und eine Datenbank ist. Echte Produkte wachsen darüber hinaus: das Content-Team will ein CMS, der Katalog will eine Bild-Pipeline, der Shop will eine echte E-Commerce-Engine, und die „App" sind eigentlich drei — das Produkt, eine Marketing-Site, eine Admin-Konsole, die sich einen Datensatz teilen.

Die Frage ist Komponierbarkeit: kann der Agent eine echte Komponente hochfahren — ein Directus, ein WordPress, einen Cache, den du kontrollierst — statt eine schlechtere Version im App-Code von Hand zu stricken, und kann ein Projekt mehr als eine App halten?

Adorables Einheit ist ein Projekt = ein isolierter Kubernetes-Namespace, und darin komponierst du:

• Services aus einem Katalog, jeder mit eigenem Container, Deployment und DNS-Namen, deployt in Abhängigkeitsreihenfolge (ein readyCheck gatet die Abhängigen): Directus (Headless-CMS), Valkey (Redis-kompatibler Cache + Queue), MariaDB, WordPress, EverShop (E-Commerce), imgproxy (Bild-Pipeline) — neben dem Postgres der Plattform (Neon-Branch) und S3 (Garage). Füge directus hinzu und die App erreicht es unter directus:8055; füge den Cache hinzu und es ist redis:6379. Der Agent provisioniert und verdrahtet sie; du fügst keine Connection Strings ein.
• Mehrere Apps, jede mit eigenem Pod und eigener Subdomain (shop-{id}, admin-{id}, {id}), alle teilen sich den einen Postgres-Branch des Projekts, Redis, S3 und Namespace. Nicht ein Pod, der viele vortäuscht — separate Deployments, die sich Zustand teilen, mit Resource Quota und Network Policy um das ganze Projekt gezogen.

Die Aufteilung erfolgt nach Gewicht: schwere, unabhängig deployte Komponenten (ein CMS, ein Cache, eine zweite App) bekommen eigene Pods; eine App und ihre eigene tRPC-API laufen zusammen in einem Container. Du komponierst echte Komponenten, statt das Modell zu bitten, sie neu zu erfinden.

Hier eine echte Form — ein Storefront-Projekt mit zwei Apps und drei Services:

Zwei Apps und drei Services, jeder mit eigenem Pod, in einem Namespace mit einer einzigen ResourceQuota und NetworkPolicy um das Ganze — bei Idle auf null eingefroren, per Kubernetes-DNS verdrahtet, sich einen Neon-Postgres-Branch und einen S3-Bucket teilend. Der Agent provisioniert und verbindet das alles; der Boot läuft in Abhängigkeitsreihenfolge — die Datenbank und der Object Store bestehen Health Checks, bevor Directus startet (seine deklarierten Abhängigkeiten), das bereit ist, bevor die Apps Traffic bedienen.

Keiner der vier macht das:

• Lovable, Bolt, v0 geben dir eine App und eine Managed-Datenbank. Du willst ein CMS, einen Cache, den du kontrollierst, eine E-Commerce-Engine oder eine zweite App, die sich die Daten der ersten teilt? Du verlässt das Tool und verdrahtest Drittanbieter-SaaS von Hand — und nichts besitzt das ganze Set als eine isolierte Umgebung.
• Replit führt einen echten Container aus, aber seine Einheit ist eine App. Eine abhängigkeitsgeordnete Flotte (WordPress + MariaDB oder Directus + Postgres + ein Image-Proxy) plus mehrere Apps, die sich eine Datenbank teilen, alle aus dem Prompt provisioniert und verdrahtet, ist nicht sein Modell.

Wo die anderen wirklich besser sind

Kein Geschwafel heißt, das klar zu sagen:

• Breite an Managed Primitives: Supabase — unter Lovable wie unter Bolt — ist eine tiefere Managed-Backend-Oberfläche als unsere heute. Mehr Auth-Provider out of the box, eine ausgereifte Storage-API, erstklassiges Realtime. Wir beanspruchen keine Parität bei der eingebauten Oberfläche.
• Deploy-Pipeline und Edge-Netz: Vercel ist das beste Deployment-Substrat der Kategorie. Preview pro Branch, globales Edge, sofortige Rollbacks von Code, Vercel Blob — v0 erbt das alles. Wenn deine App Edge-first ist und du schon auf Vercel lebst, ist das ein echter Zug.
• First-Party-Breite in einer Box: Replit besitzt den größten Teil seines Stacks — IDE, Container, Postgres, Auth, Object Storage, Secrets, Always-on-Deploys auf Reserved-VM. Architektonisch ist es das Nächste an uns, und für viele Apps ist genau die Breite der Punkt.

Wenn du den breitesten Katalog vorverdrahteter Backend-Features willst, sind das die Tools. Wir optimieren auf etwas anderes: das Backend ist ein echter Prozess, und der Deploy ist in Code und Daten umkehrbar.

Das Raster

	Backend läuft als	Service-Komposition / Multi-App	Datenbank	Deploy → Daten	Code+Daten-Rollback
Lovable	Supabase Edge Functions	Eine App + Supabase	Supabase (Lovable Cloud)	Tägliches DB-Backup (~14 Tage)	Wiederherstellung aus täglichem Snapshot
v0	Vercel serverless/edge	Eine App + deine DB	BYO (AWS / Snowflake / Marketplace)	Code ausliefern → deine DB	Nur Code
Bolt	WebContainer (dev) → Bolt Cloud/Netlify	Eine App	Bolt Cloud oder Supabase	Code ausliefern → verbundene DB	Nur Code
Replit	Echter Container	Eine App	First-Party-Postgres + separate Prod-DB	Migrationen auf Prod fahren	Nur Code
Adorable	Echter Container (K8s-Namespace), friert auf null ein	Service-Katalog + Multi-App, ein Namespace	Copy-on-Write-Postgres-Timeline	Branch-Promotion + LSN-Checkpoint	Code + Daten, point-in-time

Der eine Satz

Drei dieser Tools führen kein Backend aus — sie führen Funktionen aus. Replit führt ein echtes Backend aus, gibt dir aber, wie die übrigen, eine App und kann deine Daten nicht in der Zeit zurückspulen. Adorable führt ein echtes Backend aus, komponiert eine Flotte echter Services und mehrere Apps innerhalb eines isolierten Projekts und rollt Code und Daten eines Releases auf einen kohärenten Moment zurück — inklusive der Migration, die der Agent nicht hätte fahren sollen.

Die Demo sah immer schon gleich aus. Stell die anderen drei Fragen.