SQLite в продакшене: чему Джулия Эванс научилась, запуская его на реальных задачах

Джулия Эванс публикует свои заметки о SQLite: ничего сенсационного, но очень полезно тем, кто сомневается в возможности запускать реальное приложение на этом небольшом файле.

Конкретный случай

Джулия Эванс — чьи зин и статьи обучили целое поколение разработчиков внутренним механизмам Linux, HTTP, DNS — 17 июля 2026 года опубликовала на своём блоге jvns.ca заметку под названием « Learning a few things about running SQLite ». Это не введение в тему и не религиозная проповедь: это полевой дневник человека, который запустил SQLite в продакшн на своём собственном сервисе и записал, что его удивило. Просто удовольствие.

Что можно из неё узнать

Мы не будем спойлерить статью — прочитайте её сами, она короткая и на английском, — но несколько тем регулярно всплывают в обсуждениях SQLite в продакшн и стоит их напомнить тем, кто интересуется:

1. Режим WAL: обязателен для конкурентного доступа

По умолчанию SQLite использует режим журнала DELETE, где записи блокируют чтение. В режиме WAL (Write-Ahead Logging) чтение больше не блокирует записи и наоборот:

PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;

synchronous = NORMAL (вместо FULL) допускает потерю максимум последней транзакции при резком отключении питания в обмен на значительный прирост производительности. Именно так работают Litestream и большинство современных серверов SQLite.

2. Одна записывающая и несколько читающих соединений

В отличие от PostgreSQL, SQLite не параллелит записи. Классический паттерн на Rust или Go: одно соединение для записи, пул соединений для чтения. Так работает, например, библиотека rusqlite в связке с deadpool-sqlite с таким разделением, или библиотека Go mattn/go-sqlite3 с sql.DB, где SetMaxOpenConns(1) настроен для записи.

3. Живые бэкапы: Litestream или LiteFS

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

• Litestream (автор — Бен Джонсон, также создатель BoltDB): непрерывная репликация в S3, Backblaze B2 или GCS. Потоковый WAL, быстрый рестор.
• LiteFS (тот же автор, теперь в Fly.io): идёт дальше, мультиузловая репликация с чтением с любой реплики.

4. Реальный потолок SQLite в 2026 году

SQLite легко выдерживает десятки тысяч запросов в секунду на одном файле, если включён WAL и правильно проиндексировано. Настоящий потолок — не в SQL, а в диске: NVMe локальный >> сетевой диск, EBS gp3 >> EFS. Многие провалы SQLite в продакшн происходят из-за того, что файл размещён на сетевом хранилище (например, NFS — SQLite прямо в документации sqlite.org/faq.html#q5 предупреждает об этом жирным шрифтом).

Что запомнить

Точка зрения Джулии Эванс, как всегда, проста: попробовать, измерить, записать, что нашли. Никаких «SQLite масштабируется» или «вам нужен PostgreSQL для всего серьёзного». Просто: это поведение меня удивило, вот почему, вот что я изменила.

Для любого разработчика, который сомневается, стоит ли доставать тяжёлую артиллерию реляционных баз для односерверного приложения или side-проекта, такая статья стоит сотни синтетических бенчмарков.