Содержание
Коротко
DBOS доказали, что для durable execution не нужен отдельный оркестратор — достаточно базы, которой вы уже доверяете. Obelisk идёт дальше: для большого класса систем SQLite + Litestream хватает, чтобы хранить состояние workflow у AI-агентов. Postgres остаётся выбором для HA и общей масштабируемости.
Что произошло
Идея durable execution часто связывают с тяжёлой инфраструктурой. На практике долговечным является не compute, а состояние workflow: лог выполнения, история шагов, возможность replay и retry активностей. Compute может быть дешёвым и одноразовым.
Obelisk строит модель вокруг execution log: прогресс workflow переживает перезапуски, активности можно повторять, состояние легко инспектировать. Для этого не обязательно поднимать сетевую СУБД.
SQLite даёт транзакционное durable-состояние без отдельного database-сервиса: нет сетевого hop, нет лишнего control plane. Локальный файл — ровно тот уровень сложности, который нужен многим экспериментальным и agent-системам.
Litestream закрывает вопрос переносимости: асинхронно стримит изменения SQLite в S3-совместимое object storage. Рабочая база остаётся рядом с runtime, а копии уходят на backup, миграцию и отладку. Важная оговорка: репликация асинхронная — при потере volume до flush можно потерять последние записи. Для AI-экспериментов это часто приемлемо, для HA shared database — нет.
Типичная схема: Obelisk-сервер с SQLite, Litestream в object storage, observer подтягивает интересные базы для replay и разбора поведения агента.
Почему это важно
AI-агенты и AI-generated workflows часто bursty, экспериментальны и лучше изолируются, когда у каждого tenant или агента свой маленький контур состояния. Флот micro VM или контейнеров с локальным SQLite и backup в S3 проще, дешевле и даёт лучшую fault isolation, чем один большой always-on Postgres.
Урок для архитекторов:
- Не стартуйте с Postgres, если state ещё не требует shared HA.
- Durable ≠ distributed: workflow state в файле SQLite уже «долговечен» в рамках одного узла.
- Litestream превращает SQLite из «локальной игрушки» в переносимый артефакт для аудита и отладки.
Postgres в Obelisk остаётся правильным выбором, когда нужны высокая доступность, широкая shared-масштабируемость или синхронная модель durability, которую async replication в S3 не даёт.
На практике
Если проектируете durable workflows для агентов или internal automation:
- Начните с SQLite на узле + Litestream в bucket; не тащите managed Postgres «на всякий случай».
- Явно зафиксируйте RPO/RTO: async backup подходит для dev/staging и исследовательских агентов, не для billing-critical state.
- Держите execution log inspectable: одна SQLite-файл — удобный артефакт для replay и post-mortem.
- Переходите на Postgres, когда появляются несколько writer’ов, строгий SLA uptime или cross-region доступ к одному state.
Дешёвые worker’ы вокруг локальной SQLite дают durable-систему с минимальной инфраструктурой — для мира AI-агентов это может быть разумный default.
Итог
Тезис «SQLite is all you need» — не отказ от Postgres навсегда, а правильный старт по сложности state: локальная транзакционная БД, Litestream для переносимости, Postgres когда HA и shared scale становятся реальными требованиями. Имеет смысл читать оригинал, если строите orchestration для агентов и не хотите переплачивать за инфраструктуру на day one.