Автор делится опытом использования SQLite на сайте под Django. Он включил WAL mode, как советовали все блоги, и надеялся на лучшее. Но столкнулся с проблемой: запрос с FTS5 (полнотекстовый поиск) на таблице из 4000 строк выполнялся 5 секунд. Решение оказалось простым — запустить ANALYZE. После этого время выполнения упало до 0.05 секунды. ANALYZE генерирует статистику о количестве строк в таблицах, чтобы планировщик запросов работал эффективнее.
Другая проблема — удаление большого числа строк. Команда DELETE выполнялась дольше 5 секунд, и другой воркер, пытавшийся записать в базу в это же время, получал таймаут и крашился. Автор решил это пакетной обработкой — удаляет строки маленькими порциями. Он признаёт, что теперь понимает, зачем нужна «настоящая» база вроде Postgres с поддержкой нескольких одновременных писателей.
Бэкапы — ещё одна боль. Первый способ: restic — через VACUUM INTO, сжатие gzip, загрузка в S3, затем restic forget и prune. Но иногда процесс убивается по OOM, и приходится делать unlock. Второй способ: Litestream — просто конфиг и команда litestream replicate. Автор поставил retention: 400h в надежде сохранить историю, но не уверен, что это работает. Он бэкапит на AWS, но возиться с генерацией credentials в консоли AWS надоело — подумывает перейти на другой S3-совместимый сервис.
В прошлом проекте Mess with DNS автор разделил таблицы на три отдельных SQLite-файла — так удобнее, потому что не все таблицы нужны в одной базе. Этот проект живёт на SQLite с 2022 года, и переезд с Postgres оказался удачным.
Забавно, что автор использует SQLite для веб-проектов с 2022-го, а о существовании ANALYZE узнал только сейчас. Через год-другой он надеется открыть для себя ещё какую-нибудь базовую возможность.