Adorable против Lovable, v0, Bolt и Replit: где на самом деле работает ваш бэкенд

Генерация — решённая задача. Lovable, v0, Bolt, Replit и Adorable превратят абзац текста в работающее приложение с базой данных под капотом. Если ваше сравнение останавливается на «может ли он собрать CRUD-приложение по промпту» — проходят все, и вопрос сводится к вкусу.

Поэтому перестаньте сравнивать демо. Эти продукты по-настоящему различают три архитектурных вопроса, и ни один из них не попадает на страницу с ценами:

1. Где физически выполняется код вашего бэкенда? 2. Что деплой делает с вашими данными — и можно ли это откатить? 3. Сколько движущихся частей может быть у вашего бэкенда — и кто их связывает?

Всё, что ниже, измеряется по этим трём осям, по состоянию на июнь 2026-го. Мы будем конкретны там, где конкуренты действительно сильны, потому что честная версия полезнее лестной.

Ось 1: где работает бэкенд

В этой категории есть ровно три ответа, и у них очень разные последствия.

Serverless-функции — Lovable, v0, Bolt (в продакшене). Ваш «бэкенд» — это набор stateless-обработчиков. Lovable запускает их как Supabase Edge Functions (Deno); v0 запускает Next.js route handlers и server actions как Vercel Functions; продакшен-таргет Bolt запускает их на Bolt Cloud или Netlify. Постоянного процесса нет. Каждый запрос будит изолят, отрабатывает и умирает.

Эта модель отлично подходит для request/response CRUD и по-настоящему тяжело даётся со всем, что требует состояния: долгоживущий WebSocket, очередь задач внутри процесса, тёплый кэш, воркер, разгребающий бэклог, задача, которая бежит две минуты. Ни одному из этого не во что поселиться — нет процесса. Вернуть их можно только прикрутив ещё managed-сервисов (отдельную очередь, отдельный realtime-сервер, отдельный cron-продукт).

Браузер — Bolt (в разработке). Dev-рантайм Bolt — это WebContainer: Node, скомпилированный в WASM, который выполняет ваш бэкенд во вкладке браузера, пока вы редактируете. Это быстрый и остроумный цикл разработки. Но это не то место, где живёт приложение — персистентность и продакшен всё равно передаются Bolt Cloud / Supabase / Netlify. То, что вы редактируете, и то, что обслуживает пользователей, — два разных рантайма.

Настоящий контейнер — Replit и Adorable. Replit запускает ваш бэкенд как реальный долгоживущий процесс в Linux-контейнере, и мы тоже. Это единственная модель, где обычный сервер ведёт себя как обычный сервер: держит соединения, гоняет фоновые воркеры внутри процесса, хранит состояние между запросами.

Форма Adorable: каждый проект — это собственный namespace Kubernetes с реальным app-подом — Vite + сервер на tRPC/Express — поверх реального Postgres. Не набор функций; процесс. Когда он простаивает, всё это замораживается (freezer cgroup v2, swap высвобождается), а compute Postgres масштабируется до нуля, так что «настоящий сервер» не означает «сервер, за который вы платите круглосуточно». Это значит, что сервер существует, хранит состояние и не стоит ничего, пока на него никто не смотрит.

Практический вывод: три из пяти не запускают бэкенд, они запускают функции. Если ваше приложение — это формы поверх данных, всё в порядке. Если в нём есть воркер, сокет или долгая задача, модель функций заставляет собирать его из деталей; модель контейнера просто запускает его.

Ось 2: что деплой делает с вашими данными

Это та ось, которую чекбоксы «prod vs. preview environment» затуманивают.

Для serverless-конструктора «деплой» означает: опубликовать новый набор функций и направить его на базу, которую вы подключили. Код версионируется (это git); данные — это одна живая база, в которую каждый деплой пишет напрямую. Индустрия начала прикрывать этот разрыв:

• Lovable делает ежедневный бэкап базы проекта (примерно 14 дней хранения, согласно докам). Это реальная точка восстановления — но это ежедневный снапшот, от которого вы катитесь вперёд, а не ветка, от которой можно форкнуть всё окружение в произвольный момент времени.
• v0 на самом деле сделал работу с данными сложнее: он подключается к базе, которую вы уже эксплуатируете (базы AWS или Snowflake либо провайдер из маркетплейса) — кнопки «создать базу данных» нет. Слой данных ваш — вам его провиженить, мигрировать и защищать.
• Replit требует отдельную продакшен-базу для деплоев — реальная изоляция между dev и prod, ближайшая из четвёрки к нашей модели, теперь работающая на собственной инфраструктуре баз данных Replit, а не на стороннем сервисе. Но деплой всё равно — это «выкатить код, прогнать миграции против прода», с тем же односторонним риском для данных, который несёт каждая миграция.

Adorable относится к этому иначе, потому что база — это таймлайн Postgres с копированием при записи (self-hosted Neon), а не сервер, который вы дампите и восстанавливаете:

• Продакшен — это долговечная ветка. Первый деплой форкает dev в прод-таймлайн с собственными данными. Повторные деплои сохраняют этот таймлайн — прод-данные реальных пользователей переживают релизы. Выход в прод не двигает ни байта; это продвижение ветки, а не миграция.
• Каждый релиз пинит git-коммит и ставит чекпоинт LSN перед деплоем на голове прода, прежде чем применить ожидающие миграции. Этот чекпоинт — обязательный якорь отката, а не опциональный бэкап.
• Откат восстанавливает код и данные. Откатитесь к релизу N — и вы получите переразвёрнутый запиненный коммит N и форк прод-данных из чекпоинта эпохи N. Git и так даёт любому инструменту откат кода. Больше ничто здесь не даёт вам откат данных, привязанный к тому же моменту.
• Агент снапшотит сам себя перед рискованными операциями. Перед деструктивной миграцией или массовым редактированием он делает чекпоинт; если операция ломает данные, он откатывается — копирование при записи, так что строка подключения не меняется.

Последний пункт — тот, у которого нет эквивалента ни у одного из четырёх. AI-агент рано или поздно выполнит DROP COLUMN на не той колонке. Git вас не спасёт, потому что git версионирует код, а не строки. Ежедневный бэкап помогает, только если вы заметите до следующего снапшота, и он восстанавливает всю базу, а не одну таблицу. Путешествие во времени по коду и данным оставляет между ошибкой и её отменой один форк на нужный момент.

Ось 3: сколько движущихся частей может быть у вашего бэкенда?

Модель «функции плюс одна база данных» исходит из того, что ваш бэкенд — это одно приложение и одна база. Реальные продукты её перерастают: контент-команде нужна CMS, каталогу — пайплайн для картинок, магазину — настоящий e-commerce-движок, а «приложение» на деле — это три: сам продукт, маркетинговый сайт, админ-консоль, разделяющие один набор данных.

Вопрос в композируемости: может ли агент поднять реальный компонент — Directus, WordPress, управляемый вами кэш — вместо того чтобы накатать худшую версию в коде приложения, и может ли один проект держать больше одного приложения?

Единица Adorable — это проект = один изолированный namespace Kubernetes, и внутри него вы компонуете:

• Сервисы из каталога, каждый — собственный контейнер, Deployment и DNS-имя, деплоящиеся в порядке зависимостей (readyCheck гейтит зависимые): Directus (headless CMS), Valkey (Redis-совместимый кэш + очередь), MariaDB, WordPress, EverShop (e-commerce), imgproxy (пайплайн картинок) — рядом с платформенными Postgres (ветка Neon) и S3 (Garage). Добавьте directus — и приложение достучится до него по directus:8055; добавьте кэш — и это redis:6379. Агент провиженит и связывает их; вы не вставляете строки подключения руками.
• Несколько приложений, каждое — собственный под и субдомен (shop-{id}, admin-{id}, {id}), все разделяющие одну ветку Postgres проекта, Redis, S3 и namespace. Не один под, притворяющийся многими — отдельные деплойменты, разделяющие состояние, с resource quota и network policy, очерченными вокруг всего проекта.

Разделение — по весу: тяжёлые, независимо деплоящиеся компоненты (CMS, кэш, второе приложение) получают собственные поды; приложение и его собственный tRPC-API работают вместе в одном контейнере. Вы компонуете реальные компоненты вместо того, чтобы просить модель изобретать их заново.

Вот реальная форма — проект-витрина с двумя приложениями и тремя сервисами:

Два приложения и три сервиса, каждый — собственный под, в одном namespace с единой ResourceQuota и NetworkPolicy вокруг всего этого — заморожены до нуля при простое, связаны через DNS Kubernetes, разделяют одну ветку Neon Postgres и один бакет S3. Агент провиженит и соединяет всё это; загрузка идёт в порядке зависимостей — база и объектное хранилище проходят health-проверки прежде, чем стартует Directus (его объявленные зависимости), который готов прежде, чем приложения начинают обслуживать трафик.

Ни один из четвёрки этого не делает:

• Lovable, Bolt, v0 дают вам одно приложение и одну managed-базу. Нужна CMS, управляемый вами кэш, e-commerce-движок или второе приложение, разделяющее данные первого? Вы выходите из инструмента и связываете сторонний SaaS руками — и ничто не владеет всем набором как одним изолированным окружением.
• Replit запускает настоящий контейнер, но его единица — одно приложение. Флот в порядке зависимостей (WordPress + MariaDB или Directus + Postgres + image-прокси) плюс несколько приложений, разделяющих одну базу, всё это провижененное и связанное из промпта, — не его модель.

В чём конкуренты действительно лучше

Без воды — значит сказать это прямо:

• Широта managed-примитивов: Supabase — под Lovable и под Bolt — это более глубокая managed-backend-поверхность, чем наша на сегодня. Больше auth-провайдеров из коробки, зрелый storage API, first-class realtime. Мы не претендуем на паритет по площади встроенного функционала.
• Деплой-пайплайн и edge-сеть: Vercel — лучший деплой-субстрат в категории. Preview на каждую ветку, глобальный edge, мгновенные откаты кода, Vercel Blob — v0 наследует всё это. Если ваше приложение edge-first и вы уже живёте на Vercel, это реальный аргумент.
• Широта first-party в одной коробке: Replit владеет бóльшей частью своего стека — IDE, контейнер, Postgres, auth, объектное хранилище, секреты, always-on-деплои на reserved-VM. Архитектурно это самое близкое к нам, и для многих приложений именно широта и есть суть.

Если вам нужен самый широкий каталог предсвязанных backend-фич — это те инструменты. Мы оптимизируем под другое: бэкенд — это реальный процесс, а деплой обратим в коде и в данных.

Сетка

	Бэкенд работает как	Композиция сервисов / мульти-app	База данных	Деплой → данные	Откат кода+данных
Lovable	Edge-функции Supabase	Одно app + Supabase	Supabase (Lovable Cloud)	Ежедневный бэкап БД (~14 дней)	Восстановление из ежедневного снапшота
v0	Vercel serverless/edge	Одно app + ваша БД	BYO (AWS / Snowflake / маркетплейс)	Выкатить код → ваша БД	Только код
Bolt	WebContainer (dev) → Bolt Cloud/Netlify	Одно app	Bolt Cloud или Supabase	Выкатить код → подключённая БД	Только код
Replit	Настоящий контейнер	Одно app	First-party Postgres + отдельная прод-БД	Прогон миграций на проде	Только код
Adorable	Настоящий контейнер (namespace K8s), замерзает до нуля	Каталог сервисов + мульти-app, один namespace	Таймлайн Postgres с копированием при записи	Продвижение ветки + чекпоинт LSN	Код + данные, point-in-time

Одно предложение

Три из этих инструментов не запускают бэкенд — они запускают функции. Replit запускает настоящий бэкенд, но, как и остальные, даёт вам одно приложение и не умеет путешествовать во времени по вашим данным. Adorable запускает настоящий бэкенд, компонует флот реальных сервисов и несколько приложений внутри одного изолированного проекта и откатывает код и данные релиза к одному согласованному моменту — включая миграцию, которую агенту не стоило запускать.

Демо всегда будет выглядеть одинаково. Задайте остальные три вопроса.