Разработчик заменил десять SaaS-сервисов на Go и SQLite — и выжил

Проект Obelisk утверждает: для большинства систем с устойчивым состоянием SQLite — это всё, что вам нужно. Состояние воркфлоу — это то, что должно быть надёжным; вычисления остаются дешёвыми и одноразовыми. SQLite даёт транзакционное хранение без отдельного сервиса базы данных — без сетевого хопа, без дополнительного control plane. SQLite плюс Litestream для бэкапов в S3 — и этого достаточно.

В треде на HN — предсказуемая война, и первый залп делает разработчик с опытом в высоконагруженных системах: он не понимает одержимость SQLite для продакшена. SQLite — встраиваемая база данных, категорически непригодная для управления конкурентным доступом. Для этого существуют серверы баз данных. Тридцать ответов под его комментарием — и ни один не ставит точку в споре.

Потому что с другой стороны баррикад — практики, а не теоретики. Один инженер перечисляет, что он заменил связкой Go и SQLite: Intercom, Zendesk, email-маркетинг, канбан, трекер задач, биллинг, форум, мониторинг аптайма, клон PagerDuty — больше десяти сервисов. И всё работает. Другой сообщает: у них семизначный MAU, и всё работает на SQLite durable objects. Не прототип, не пет-проект — продакшен с миллионами активных пользователей.

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

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

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