Зміст
Коротко
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.