Litestream: как держать SQLite в проде и не бояться

Проблема

SQLite — самая распространённая база данных в мире, но в веб-проектах её обычно боятся использовать в проде. Не из-за скорости: на одном сервере она обгоняет Postgres в большинстве типовых сценариев чтения. Страх в другом — файл базы лежит на диске, диск может умереть, и «сделать дамп по крону» звучит как план, пока не выясняется, что последний дамп был позавчера.

Что делает Litestream

Litestream — небольшая программа на Go, которая запускается рядом с приложением и следит за файлом базы. SQLite в режиме WAL пишет изменения в отдельный журнал, а Litestream читает этот журнал и отправляет сегменты в объектное хранилище: S3, любой S3-совместимый сервис, SFTP или просто другую директорию.

В результате в хранилище лежит полный снимок базы и непрерывная цепочка изменений после него. Восстановиться можно на любой момент времени в пределах срока хранения:

litestream restore -o app.db s3://my-bucket/app.db

Задержка репликации — секунды. Если сервер сгорел, вы теряете последние несколько секунд записи, а не сутки.

Конфигурация

Весь конфиг помещается в десяток строк:

dbs:
  - path: /data/app.db
    replicas:
      - url: s3://my-bucket/app.db
        retention: 72h

Запуск — litestream replicate, либо Litestream сам стартует приложение как дочерний процесс и следит за ним. В Docker это удобно: один контейнер, один entrypoint.

Чего Litestream не делает

Это не кластер и не многомастерная репликация. Писать по-прежнему может только один процесс на одной машине. Если нужен горячий резерв с чтением на нескольких узлах, смотрите в сторону LiteFS или полноценных серверных СУБД.

Ещё Litestream не заменит бэкап в другом регионе, если хранилище и сервер живут у одного провайдера и провайдер ляжет целиком. Но это уже вопрос о том, где лежат реплики, а не об инструменте.

Почему это важно

Связка «SQLite + Litestream» возвращает в моду самый простой деплой из возможных: один бинарник, один файл базы, один сервер. Без пула соединений, без миграции на managed-базу за деньги, без отдельного контейнера с Postgres, который тоже надо бэкапить.

Для контентных сайтов, внутренних инструментов, небольших SaaS и всего, что живёт на одной машине, это честный вариант. И с ним проще спать по ночам.