SQLite для durable workflows: хватит раздувать инфраструктуру

SQLite для durable workflows: достаточно одного файла

Команда Obelisk опубликовала материал, в котором оспаривает популярный тезис: для надёжного выполнения рабочих процессов (durable execution — выполнение, которое переживает сбои и перезапуски) не нужна тяжёлая инфраструктура. SQLite привлекателен тем, что даёт транзакционное надёжное хранилище без отдельного сервиса базы данных — никаких сетевых переходов, никакого дополнительного control plane. Дискуссия разгорелась на Hacker News и набрала несколько сотен комментариев.

Контекст: спор о базах данных для воркфлоу

Несколько месяцев назад компания DBOS выдвинула аргумент: цель DBOS — сделать durable workflows как можно более лёгкими и простыми в работе, используя Postgres в качестве единственного слоя хранения. DBOS использует Postgres как единственную зависимость — без отдельного брокера, оркестратора или control plane.

Оbelisk идёт дальше и предлагает ещё более радикальное упрощение: для большинства задач достаточно SQLite.

Почему SQLite — это не упрощение, а правильный выбор

В Obelisk прогресс воркфлоу хранится в журнале выполнения, воркфлоу воспроизводятся из сохранённой истории, а активности можно повторять. Главное — держать состояние воркфлоу под рукой и в удобном для инспекции виде.

Каждый вызов, sleep и результат сохраняются в журнале выполнения. Сбой посреди воркфлоу — при перезапуске система возобновляется с последнего завершённого шага.

«Надёжная часть — это состояние воркфлоу. Вычисления могут оставаться дешёвыми и одноразовыми.»

Obelisk поставляется как единый бинарник со встроенным SQLite или Postgres — без брокеров, sidecar-контейнеров и YAML-пайплайнов.

Litestream: как перенести SQLite в облако

Очевидный вопрос — что делать с файлами SQLite по мере накопления экспериментов. Здесь на помощь приходит Litestream: он умеет стримить изменения SQLite асинхронно в S3-совместимое объектное хранилище.

Litestream — инструмент потоковой репликации для SQLite. Он следит за Write-Ahead Log и непрерывно отправляет изменения в S3-совместимое хранилище. Восстановление — это просто восстановление из потока.

Пример минимальной конфигурации Litestream:

# litestream.yml
dbs:
  - path: /data/workflows.db
    replicas:
      - url: s3://my-bucket/workflows.db

Архитектура: флот мини-серверов вместо одного монолита

graph LR
    A[AI-агент / воркфлоу] --> B[Obelisk Server]
    B --> C[(SQLite DB)]
    C --> D[Litestream]
    D --> E[(S3-совместимое хранилище)]
    E --> F[Отладка / Replay / Миграция]
    style C fill:#f0f4ff,stroke:#4a6cf7
    style E fill:#f0fff4,stroke:#38a169

Рабочая модель выглядит так: запустить сервер Obelisk с базой SQLite, делать резервные копии через Litestream, а при необходимости извлекать нужные базы. Один и тот же файл можно использовать для локального воспроизведения, отладки и анализа действий агента.

Это особенно привлекательно для AI-агентов и воркфлоу, сгенерированных ИИ. Такие системы часто работают в burst-режиме, носят экспериментальный характер, и с ними проще работать, когда каждый агент или арендатор имеет небольшую самодостаточную единицу состояния. Флот крошечных серверов в micro-VM или контейнерах, каждый со своей SQLite и резервной копией в объектном хранилище, нередко лучше, чем одна большая постоянно работающая общая система.

Это удобно для локальной разработки и определённых сценариев развёртывания, где несколько секунд простоя при передеплое приемлемы. Такой подход позволяет развернуть Obelisk на сотнях VM, не разделяя ничего, кроме S3-эндпоинта для бэкапов.

SQLite vs Postgres: когда что выбирать

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

Контекст: большая дискуссия о durable execution

Durable execution перестал быть нишевой темой в 2025 году. Агентные AI-пайплайны с десятками LLM-вызовов, долгоживущие саги с платежами и инвентарём, event-driven задачи, которые должны пережить перезапуск пода — все сошлись на одном примитиве: функция, которая возобновляется ровно с того места, где остановилась после сбоя.

Исторически надёжность воркфлоу ассоциировалась с мощными сетевыми базами данных вроде Postgres. Однако последние дискуссии, особенно на Hacker News, показывают: для многих сценариев локальные базы с асинхронной репликацией вполне справляются. Это отражает более широкий тренд на минимальную инфраструктуру для AI и экспериментальных воркфлоу.

Вывод

Tезис прост: не усложняйте инфраструктуру раньше, чем это реально потребуется. Для AI-агентов, экспериментальных систем и burst-нагрузок SQLite в связке с Litestream — это не временный костыль, а продуманная архитектура. Архитектура «один файл, нулевые зависимости» SQLite оказывается преимуществом на краях распределённых систем — там, где нужно вычисление рядом с данными без накладных расходов клиент-серверной базы данных.