SQLite для разработчика: когда встроенной БД достаточно

Прямой ответ

SQLite — самая развёрнутая СУБД в мире (она в каждом телефоне и браузере), и в 2026 году её границы заметно расширились: WAL-режим даёт уверенную конкурентность «много читателей + один писатель», производительность на современном SSD измеряется десятками тысяч транзакций в секунду, а аналитические запросы к файлам данных делают её инструментом локального аналитика. Критерий выбора простой: одно приложение, один процесс-писатель, данные до сотен ГБ — SQLite часто лучше серверной БД (ноль администрирования, бэкап = копирование файла, деплой без инфраструктуры). Много одновременных писателей, сеть, репликация — это территория PostgreSQL из статьи про локальную БД разработчика.

Где SQLite объективно силён

Встроенная БД приложения: desktop-утилиты, CLI-инструменты, мобильные приложения, локальные кэши — штатная ниша. Файл БД перемещается вместе с приложением; миграции версионируются кодом.
Прототипы и MVP: веб-приложение на Django/Rails/Laravel с SQLite стартует без единого сервиса; переезд на PostgreSQL — смена конфига при корректно написанных запросах (избегайте диалект-специфики с первого дня).
Локальная аналитика: CLI sqlite3 и библиотеки читают CSV/parquet-подобные данные через внешние таблицы; связка «SQLite + Python» закрывает задачи, где раньше заводили сервер — контекст в статье про аналитический стек.
Тесты и фикстуры: in-memory SQLite (:memory:) — мгновенные прогоны для логики, не завязанной на диалект; для диалект-специфичного — testcontainers с настоящим PostgreSQL.
Хранилище артефактов: индексы, очереди задач одного воркера, история операций — один файл, понятный бэкап.

Конкурентность без мифов

Устаревшее «SQLite блокирует всё» описывает режим rollback-journal. В WAL (write-ahead logging) читатели не блокируют писателя и наоборот:

PRAGMA journal_mode=WAL;      -- включить один раз, сохраняется в файле
PRAGMA synchronous=NORMAL;    -- баланс надёжности и скорости для WAL
PRAGMA busy_timeout=5000;     -- ждать разблокировки вместо мгновенной ошибки

Реальное ограничение WAL: писатель в каждый момент один (очередь на запись). Для веб-приложения с умеренной нагрузкой (десятки записей в секунду) этого хватает; для высоконагруженной записи или распределённой системы — нет. Отсюда народное правило: «SQLite выдерживает больше, чем большинство приложений, которые его боятся, и меньше, чем обещают энтузиасты».

Ограничения, о которые спотыкаются

Сетевой доступ: SQLite — файловая библиотека, не сервер; «подключиться к SQLite по сети» — антипаттерн (NFS/SMB-файл под БД ведёт к повреждениям).
Типизация мягче PostgreSQL: динамическая типизация колонок прощает ошибки, которые серверная БД отвергла бы; дисциплину наводит STRICT-режим таблиц (3.37+).
Ограниченный набор типов и функций (нет массивов, JSON частично, полнотекст через FTS5-модуль) — проверяйте нужные возможности до выбора.
VACUUM и рост файла: удаление данных не уменьшает файл автоматически; периодический VACUUM (или auto_vacuum=INCREMENTAL) возвращает место.
Бэкап на живой базе — не копированием файла, а sqlite3 .backup / VACUUM INTO: копирование пишущейся БД даёт повреждённый снимок.

Критерии перехода на серверную БД

Чек-лист «пора мигрировать»: несколько процессов/инстансов пишут одновременно; нужен доступ с других машин; появились требования репликации/HA; объём записи упирается в очередь единственного писателя; запросы требуют возможностей диалекта (CTE-окна есть и в SQLite, а вот партиционирование и продвинутые блокировки — нет). Миграция при аккуратной разработке механистична: дамп схемы и данных, правка строки подключения, прогон тестов против новой БД (лучше — изначально написанных через testcontainers).

Практика разработки

Инструменты: CLI sqlite3 (обязательно выучить .schema, .tables, .mode column), GUI — DBeaver/DataGrip; для веба — Datasette (превращает SQLite-файл в browsable API). Проектирование: WAL и busy_timeout включайте с первой миграции (задним числом — тоже можно); внешние ключи включаются прагмой на каждое соединение (PRAGMA foreign_keys=ON) — забывчивость здесь классический баг; индексы те же, что в любой БД. Для Jupyter-сценариев: %load_ext sql + строка подключения к файлу — SQL-запросы прямо в ноутбуке, подход к большим файлам — в статье про Jupyter и память.

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

FAQ

Правда ли, что на SQLite работают продакшен-сайты? Да, при профиле «много чтения, умеренная запись» (контент-сайты, внутренние инструменты). Решение всегда по нагрузке, не по престижу СУБД.

SQLite или PostgreSQL для нового веб-проекта? Если проект соло/прототип — SQLite ускоряет старт и деплой. Если команда и рост — сразу PostgreSQL: миграция потом дороже, чем контейнер с БД сейчас.

Как перенести SQLite-базу между машинами? Остановить запись, sqlite3 app.db "VACUUM INTO 'backup.db'" — и копия готова к переносу; целостность проверяется PRAGMA integrity_check.

Подходит ли SQLite как кэш вместо Redis? Для персистентного кэша одного процесса — да (таблица с TTL и индексом). Для общего кэша нескольких сервисов — нет: это снова упирается в одного писателя и файловый доступ.

Производительность: цифры для калибровки

Чтобы выбор был осознанным, полезны порядки величин на современном NVMe-ноутбуке: точечные вставки в WAL-режиме с synchronous=NORMAL — десятки тысяч транзакций в секунду при группировке (batch), единицы тысяч без группировки; чтение — сотни тысяч запросов в секунду из page cache; база в 10 ГБ с хорошими индексами отвечает на точечные запросы за миллисекунды. Узкие места почти всегда не в движке, а в паттернах: тысяча отдельных INSERT вместо одного батча в транзакции (разница в 50–100 раз), запросы без индексов по миллионным таблицам, частые мелкие транзакции с synchronous=FULL.

Практический вывод: до оптимизации включите WAL, батчьте запись и постройте индексы — эти три действия решают девять десятых «SQLite тормозит». Оставшаяся десятая — реальные границы одного писателя, и они лечатся только сменой архитектуры в сторону серверной БД.

Можно ли открыть производственную базу SQLite для разбора инцидента? Да, и это одно из её преимуществ: скопируйте файл (лучше через VACUUM INTO на живой базе) и откройте локально любым клиентом — сервер не нужен. Только не работайте с оригиналом на месте и помните про чувствительные данные в копии.

Подходит ли SQLite для очередей задач? Для одного воркера — да, это известная рабочая схема (таблица задач с статусом и индексом). Для конкурирующих воркеров на нескольких машинах — нет: снова ограничение единственного писателя и файловый доступ.

Есть ли смысл в SQLite для мобильного приложения в 2026? Да, это по-прежнему стандарт хранения на мобильных платформах — обе основные ОС поставляют его внутри. Альтернативы (облачная синхронизация поверх локальной базы) обычно всё равно используют SQLite как нижний слой.

Источники: документация SQLite (when to use, WAL, VACUUM) — ссылки в шапке.

SQLite в 2026: когда встроенной базы достаточно и сервер не нужен