Что такое SQLite и когда её достаточно

SQLite в двух словах

SQLite — это реляционная база данных, которая работает не как отдельный сервер, а как библиотека внутри вашего приложения. Вся база — таблицы, индексы, данные — хранится в одном обычном файле на диске. Нечего устанавливать и настраивать: нет демона, пользователей и портов. Приложение открывает файл и выполняет SQL.

При этом движок серьёзный: транзакции с гарантиями ACID, индексы, представления, триггеры, функции для JSON и большая часть стандартного SQL.

Как работает встраиваемая модель

С PostgreSQL или MySQL приложение отправляет запросы по сети серверному процессу, который владеет данными. В SQLite движок запросов встроен в само приложение и читает и пишет файл напрямую.

Что это даёт:

• Ноль администрирования — ничего не нужно отдельно запускать, обновлять и мониторить.
• Быстрое локальное чтение — нет сетевого обмена на каждый запрос.
• Простой перенос — скопировали файл, скопировали базу.
• Удобные тесты — новая база для каждого теста это новый файл или база в памяти.

Чем за это платите:

• Доступ есть только у процессов на той же машине, где лежит файл.
• Нет встроенных пользователей и ролей — кто может прочитать файл, тот видит данные.
• Писать может только один процесс одновременно. Запись блокирует базу, остальные ждут.

Где SQLite — правильный выбор

Настройки, которые стоит включить

Несколько команд PRAGMA делают SQLite заметно удобнее в реальном приложении:

PRAGMA journal_mode = WAL;    -- читатели больше не блокируют запись
PRAGMA busy_timeout = 5000;   -- ждать блокировку до 5 с вместо мгновенной ошибки
PRAGMA foreign_keys = ON;     -- внешние ключи по умолчанию выключены, для каждого соединения

Главное здесь — режим WAL (write-ahead logging): читатели и единственный писатель работают одновременно, и большинство ошибок «database is locked» в веб-приложениях исчезает. Если нужна проверка типов, посмотрите на таблицы STRICT — по умолчанию SQLite гибко относится к типам колонок.

Признаки, что пора на серверную СУБД

SQLite — не «игрушечная» база, но у неё есть реальные пределы. Переходите на PostgreSQL или MySQL, если:

• Несколько серверов приложения должны работать с одними данными. Файл базы на сетевом диске (NFS, SMB) — известный источник проблем с блокировками и повреждения данных.
• Ошибки «database is locked» повторяются даже с WAL и busy timeout — одного писателя уже не хватает.
• Много одновременных записей: чаты, обработка заказов, нагруженные API с постоянными вставками.
• Нужно разграничение доступа: отдельные пользователи, роли, read-only доступ для аналитиков.
• Нужны репликация и автоматическое переключение при сбое.
• Тяжёлые аналитические запросы начинают тормозить основное приложение.

Частые ошибки

• Хранить файл базы на сетевом диске, к которому обращаются несколько машин.
• Открывать новое соединение на каждый мелкий запрос и не включать WAL.
• Копировать файл во время записи — для согласованной копии используйте .backup в консоли sqlite3 или VACUUM INTO.
• Забывать, что foreign_keys по умолчанию выключены.