Adorable vs. Lovable, v0, Bolt, and Replit: where your backend actually runs

Generation is solved. Lovable, v0, Bolt, Replit, and Adorable will all turn a paragraph into a running app with a database behind it. If your comparison stops at "can it build a CRUD app from a prompt," every tool passes and the question is taste.

So stop comparing the demo. Three architectural questions actually separate these products, and none shows up on a pricing page:

1. Where does your backend code physically run? 2. What does a deploy do to your data — and can you undo it? 3. How many moving parts can your backend have — and who wires them?

Everything below is measured on those three axes, as of June 2026. We'll be specific about where the others are genuinely strong, because the honest version is more useful than the flattering one.

Axis 1: where the backend runs

There are exactly three answers in this category, and they have very different consequences.

Serverless functions — Lovable, v0, Bolt (in production). Your "backend" is a bundle of stateless handlers. Lovable runs them as Supabase Edge Functions (Deno); v0 runs Next.js route handlers and server actions as Vercel Functions; Bolt's production target runs them on Bolt Cloud or Netlify. There is no persistent process. Each request wakes an isolate, runs, and dies.

That model is excellent for request/response CRUD and genuinely hard for everything stateful: a long-lived WebSocket, an in-process job queue, a warm cache, a worker that drains a backlog, a task that runs for two minutes. None of those have a process to live in. You get them back only by bolting on more managed services (a separate queue, a separate realtime server, a cron product).

The browser — Bolt (in development). Bolt's dev runtime is a WebContainer: Node compiled to WASM, running your backend in the browser tab while you edit. It's a fast, clever dev loop. It is also not where the app lives — persistence and production still hand off to Bolt Cloud / Supabase / Netlify. The thing you edit and the thing that serves users are two different runtimes.

A real container — Replit, and Adorable. Replit runs your backend as an actual long-running process in a Linux container, and so do we. This is the only model where a normal server is normal: hold connections, run background workers in-process, keep state between requests.

Adorable's shape: every project is its own Kubernetes namespace running a real app pod — Vite + a tRPC/Express server — against a real Postgres. Not a function bundle; a process. When it's idle the whole thing freezes (cgroup v2 freezer, swap reclaimed) and the Postgres compute scales to zero, so "a real server" does not mean "a server you pay for around the clock." It means the server exists, holds state, and costs nothing while nobody's looking at it.

The practical line: three of the five don't run a backend, they run functions. If your app is forms-over-data, that's fine. If it has a worker, a socket, or a long task, the functions model makes you assemble it from parts; the container model just runs it.

Axis 2: what a deploy does to your data

This is the axis that the "prod vs. preview environment" checkboxes obscure.

For a serverless builder, "deploy" means: publish a new function bundle and point it at a database you connected. The code is versioned (it's git); the data is a single live database that every deploy writes straight through. The industry has started papering over the gap:

• Lovable takes a daily backup of the project database (roughly 14 days of retention, per its docs). That's a real restore point — but it's a daily snapshot you roll forward from, not a branch you can fork the whole environment off at an arbitrary point in time.
• v0 actually made data harder: it connects to a database you already operate (AWS or Snowflake databases, or a marketplace provider) — there is no "create a database" button. The data layer is yours to provision, migrate, and protect.
• Replit requires a separate production database for deploys — real isolation between dev and prod, the closest of the four to our model, now running on Replit's own database infrastructure rather than a third party. But a deploy is still "ship code, run migrations against prod," with the same forward-only data risk every migration carries.

Adorable treats this differently because the database is a copy-on-write Postgres timeline (self-hosted Neon), not a server you dump and restore:

• Production is a durable branch. The first deploy forks dev into a prod timeline with its own data. Re-deploys keep that timeline — real users' prod data persists across releases. Going live moves no bytes; it's a branch promotion, not a migration.
• Every release pins a git commit and tags a pre-deploy LSN checkpoint on prod's head before applying pending migrations. That checkpoint is a mandatory rollback anchor, not an opt-in backup.
• Rollback restores code and data. Roll back to release N and you get N's pinned commit redeployed and the prod data fork-from-checkpoint of N's era. Git already gives every tool a code undo. Nothing else here gives you a data undo bound to the same moment.
• The agent snapshots itself before risky operations. Before a destructive migration or bulk edit, it checkpoints; if the operation breaks the data, it rolls back — copy-on-write, so the connection string never changes.

That last point is the one with no equivalent in any of the four. An AI agent will eventually run DROP COLUMN on the wrong column. Git won't save you, because git versions code, not rows. A daily backup helps only if you notice before the next snapshot, and it restores the whole database, not the one table. Code+data time-travel makes the mistake a point-in-time fork away from undone.

Axis 3: how many moving parts can your backend have?

The functions-plus-one-database model assumes your backend is one app and one database. Real products outgrow that: the content team wants a CMS, the catalog wants an image pipeline, the store wants a real e-commerce engine, and the "app" is actually three — the product, a marketing site, an admin console — sharing one set of data.

The question is composability: can the agent stand up a real component — a Directus, a WordPress, a cache you control — instead of hand-rolling a worse version in app code, and can one project hold more than one app?

Adorable's unit is a project = one isolated Kubernetes namespace, and inside it you compose:

• Services from a catalog, each its own container, Deployment, and DNS name, deployed in dependency order (a readyCheck gates dependents): Directus (headless CMS), Valkey (Redis-compatible cache + queue), MariaDB, WordPress, EverShop (e-commerce), imgproxy (image pipeline) — alongside the platform's Postgres (Neon branch) and S3 (Garage). Add directus and the app reaches it at directus:8055; add the cache and it's redis:6379. The agent provisions and wires them; you don't paste connection strings.
• Multiple apps, each its own pod and subdomain (shop-{id}, admin-{id}, {id}), all sharing the project's one Postgres branch, Redis, S3, and namespace. Not one pod pretending to be many — separate deployments that share state, with the resource quota and network policy drawn around the whole project.

The split is by weight: heavy, independently-deployed components (a CMS, a cache, a second app) get their own pods; an app and its own tRPC API run together in one container. You compose real components instead of asking the model to reinvent them.

Here's a real shape — a storefront project with two apps and three services:

Two apps and three services, each its own pod, in one namespace with a single ResourceQuota and NetworkPolicy around the whole thing — frozen to zero when idle, wired by Kubernetes DNS, sharing one Neon Postgres branch and one S3 bucket. The agent provisions and connects all of it; boot is dependency-ordered — the database and object store pass health checks before Directus starts (its declared dependencies), which is ready before the apps serve traffic.

None of the four does this:

• Lovable, Bolt, v0 give you one app and one managed database. Want a CMS, a cache you control, an e-commerce engine, or a second app sharing the first's data? You leave the tool and wire third-party SaaS by hand — and nothing owns the whole set as one isolated environment.
• Replit runs a real container, but its unit is one app. A dependency-ordered fleet (WordPress + MariaDB, or Directus + Postgres + an image proxy) plus several apps sharing one database, all provisioned and wired from the prompt, isn't its model.

Where the others are genuinely better

No fluff means saying this plainly:

• Breadth of managed primitives: Supabase — under both Lovable and Bolt — is a deeper managed-backend surface than ours today. More auth providers out of the box, a mature storage API, first-class realtime. We are not claiming parity on built-in surface area.
• Deploy pipeline and edge network: Vercel is the best deployment substrate in the category. Preview-per-branch, global edge, instant rollbacks of code, Vercel Blob — v0 inherits all of it. If your app is edge-first and you already live on Vercel, that's a real pull.
• First-party breadth in one box: Replit owns the most of its stack — IDE, container, Postgres, auth, object storage, secrets, reserved-VM always-on deploys. Architecturally it's the closest thing to us, and for many apps the breadth is the point.

If you want the widest catalog of pre-wired backend features, those are the tools. We optimize for a different thing: the backend is a real process, and the deploy is reversible in code and data.

The grid

	Backend runs as	Compose services / multi-app	Database	Deploy → data	Code+data rollback
Lovable	Supabase edge functions	One app + Supabase	Supabase (Lovable Cloud)	Daily DB backup (~14-day)	Restore from daily snapshot
v0	Vercel serverless/edge	One app + your DB	BYO (AWS / Snowflake / marketplace)	Ship code → your DB	Code only
Bolt	WebContainer (dev) → Bolt Cloud/Netlify	One app	Bolt Cloud or Supabase	Ship code → connected DB	Code only
Replit	Real container	One app	First-party Postgres + separate prod DB	Run migrations on prod	Code only
Adorable	Real container (K8s namespace), freezes to zero	Service catalog + multi-app, one namespace	Copy-on-write Postgres timeline	Branch promotion + LSN checkpoint	Code + data, point-in-time

The one sentence

Three of these tools don't run a backend — they run functions. Replit runs a real backend but, like the rest, gives you one app and can't time-travel your data. Adorable runs a real backend, composes a fleet of real services and multiple apps inside one isolated project, and rolls back a release's code and data to one coherent moment — including the migration the agent shouldn't have run.

The demo was always going to look the same. Ask the other three questions.