Когда использовать SQLite: сценарии и ограничения

Главный вопрос

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

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

Когда использовать SQLite: данные живут рядом с приложением

SQLite раскрывается там, где база принадлежит одному приложению на одной машине. Файл лежит рядом с кодом, приложение открывает его напрямую — и это, по сути, вся архитектура.

-- Типичная схема "данные живут вместе с приложением":
-- локальное хранилище десктопного приложения для заметок.
CREATE TABLE notes (
    id        INTEGER PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT,
    created   TEXT DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO notes (title, body) VALUES
    ('Покупки', 'молоко, хлеб, кофе'),
    ('Идеи',    'план учебника по sqlite');

SELECT id, title, created FROM notes;

Эта крошечная схема вполне может быть бэкендом настоящего приложения. Вот несколько сценариев, где такой подход ложится естественно:

• Десктопные и мобильные приложения. Любое iOS- или Android-приложение, которому нужно структурированное локальное хранилище, под капотом использует SQLite. Туда же — Firefox, Chrome и большинство браузеров.
• CLI-утилиты. git, пакетные менеджеры, менеджеры дотфайлов — все они полагаются на встраиваемые базы.
• Встраиваемые устройства. Роутеры, автомобили, самолёты — всё, где база должна укладываться в пару сотен килобайт.
• Тесты. Свежий файл SQLite (или база :memory:) на каждый тест — это быстрее и изолированнее, чем поднимать Postgres.

Если данные не нужно расшаривать между несколькими машинами, SQLite, скорее всего, и есть правильный ответ.

SQLite для веб-приложений с большим количеством чтений

С чтениями SQLite справляется великолепно. Множество одновременных читателей, никакой конкуренции за ресурсы, время выборки по индексу — микросекунды. Если на вашем сайте люди в основном читают контент — блоги, документация, лендинги, небольшие SaaS-дашборды, — SQLite справится без проблем. Часто даже лучше, чем Postgres по сети, потому что нет накладных расходов на сетевой round-trip.

-- Таблица постов блога.
CREATE TABLE posts (
    slug      TEXT PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT NOT NULL,
    published TEXT
);

CREATE INDEX idx_posts_published ON posts(published DESC);

INSERT INTO posts VALUES
    ('hello-world', 'Привет, мир', 'Первый пост.', '2024-01-01'),
    ('sqlite-rocks', 'Почему SQLite',  'БД в одном файле.', '2024-02-15');

SELECT slug, title FROM posts ORDER BY published DESC LIMIT 10;

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

Режим WAL (write-ahead logging, разберём его позже) заметно поднимает эту планку: читатели и писатель начинают работать параллельно. На связке SQLite + WAL спокойно крутятся продакшен-сайты, обслуживающие миллионы запросов в день.

SQLite для локального кэша и временных данных

Когда нужно структурированное локальное хранилище — что-то посерьёзнее JSON-файла, но без полноценного сервера БД, — SQLite тяжело переплюнуть.

-- Таблица кэша для HTTP-клиента.
CREATE TABLE http_cache (
    url        TEXT PRIMARY KEY,
    body       BLOB NOT NULL,
    expires_at INTEGER NOT NULL
);

INSERT INTO http_cache (url, body, expires_at)
    VALUES ('https://api.example.com/users/1', x'7b2269...', 1735689600);

DELETE FROM http_cache WHERE expires_at < strftime('%s', 'now');
SELECT count(*) FROM http_cache;

Логи, буферы аналитики, staging-слои в ETL, feature store для ML, индексы IDE — всё это естественная среда обитания SQLite. Файл легко переносится, язык запросов — полноценный SQL, и при этом не нужно нянчиться с сервером.

Когда не использовать SQLite: много одновременных писателей

Это то самое ограничение SQLite, на которое все натыкаются. Здесь блокировка на запись действует на уровне всей базы: один писатель — и точка. Если два процесса попытаются вставить данные одновременно, один из них будет ждать.

Для большинства приложений это не проблема — записи случаются редко и выполняются быстро. Но если ваша нагрузка выглядит так:

• мультитенантный SaaS, где тысячи пользователей пишут одновременно;
• высоконагруженная очередь сообщений или журнал событий;
• бэкенд для онлайн-игры или чата с постоянным изменением состояния, —

то SQLite станет узким местом. У Postgres и MySQL блокировки на уровне строк, и они изначально заточены ровно под такие сценарии. В этих случаях выбор очевиден — берите их.

-- Ошибка, которую вы увидите, когда писатели накапливаются:
Error: database is locked

If you're seeing that under normal load, SQLite is the wrong tool — not a bug to work around.

SQLite не подходит, если БД нужна нескольким машинам

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

Поэтому такие сценарии отпадают:

• Несколько серверов приложений за балансировщиком, которые хотят работать с одной базой. (Сетевые файловые системы вроде NFS формально работают, но под нагрузкой портят файл. Не надо.)
• Serverless-функции, где каждый вызов запускается на отдельной машине.
• Поды в Kubernetes, которым нужна общая база — разве что вы используете одиночный под с persistent volume.

Если в вашей архитектуре больше одного процесса на больше чем одной машине пишут в базу — нужна клиент-серверная СУБД. Вот эта граница.

Когда не использовать SQLite: пользователи на уровне БД

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

Для однопользовательского десктопного приложения это нормально. А вот для многопользовательской системы, где разным людям нужны разные привилегии внутри базы, берите Postgres или MySQL.

Быстрый чек-лист для принятия решения

Пройдитесь по списку. Если на всё ответ «да» — SQLite вам, скорее всего, отлично подойдёт:

• База лежит на той же машине, что и приложение.
• С ней общается один процесс (или несколько, и в основном на чтение).
• Все данные спокойно помещаются на один диск — терабайты тоже норм, но это всё равно один диск.
• Права пользователей на уровне базы не нужны.
• Параллельные записи случаются редко, а не составляют основную нагрузку.

Если хоть где-то «нет» — смотрите в сторону Postgres или MySQL. На следующих двух страницах будет прямое сравнение sqlite vs mysql и sqlite или postgresql.

Что стоит унести с собой

• SQLite — правильный выбор, когда база живёт рядом с приложением: десктоп, мобильные приложения, встраиваемая база данных sqlite, CLI-утилиты, тесты, сайты с преобладанием чтения, локальные кэши.
• Это полноценный продакшен-уровень — SQLite крутится на миллиардах устройств. Ограничения здесь архитектурные, а не про качество.
• Не берите его, если нужны много параллельных писателей, доступ с нескольких машин или права пользователей на уровне БД.

Дальше: установка SQLite

Хватит теории. На следующей странице разберёмся, как поставить SQLite на машину — на macOS и большинстве дистрибутивов Linux он уже есть, на Windows ставится одним скачиванием — и проверим установку из командной строки.