SQLite по факту это спецификация библиотеки, которая позволяет оперировать над файлами базы данных, напрямую из языка программирования

Из преимуществ

– Благодаря тому что скорость работы SQLite зависит от скорости языка + мощности процессора + пропускной способности IO, теоритически это одна из самых быстрых БД, как минимум, потому что в ней полностью отсутствует вся сетевая сложность стандартных баз

– Если другие встроенные хранилища это просто key-value (rocksdb, leveldb, badger), или NoSQL со своим уникальным SDK (couchdb-like), то SQLite это полноценная SQL база, сравнивая по возможностям SQL с PostgreSQL: схема, индексы, транзакции, локи, джоины, констрайнты, все есть короче

– Соответственно и опыт на любой другой БД, будет релевантен, что делает SQLite очень привлекательной для разработчиков

– И из этого же вытекает то, что можно практически безболезненно пересесть со SQLite на PostgreSQL / MySQL, когда / если придет время

– Из-за своей простоты SQLite или уже интегрирован (барузер, мобилки, нативки) или легко добавляется (видел железки с минимальным Linux на борту, на которых приложения пользуют SQLite)

– Можно работать с одним инстансом сразу из нескольких процессов

– Для бэкапа БД, нужно просто закинуть файлы на S3

– Суперпростое интеграционное тестирование, потому что вы можете хоть на каждый тест свой sqlite инстанс (например, inmemory)

– Если вы создадите SaaS без multitenancy и будете распространять его как коробочное решение, то без проблем сможете открывать по инстансу на клиента

– Настолько бесплатно, насколько возможно

Из недостатков

– Классические сетевые файловые системы не позволиляют с нескольких серверов / контейнеров работать с одной и той же SQLite базой (обнаружил только информацию про VFS, но пока не понимаю насколько это рабочий вариант)

– Если что-то произойдет с файловой системой при записи данных, есть шанс поломаться так, что просто не восстановитесь

Кейсы применения

– Локальная БД для приложения с фронтом (веб, мобилки, десктопы)
– Локальная БД для удаленных агентов (приложение, которое собирает и отправляет данные в клауд с устройств, с сервера на складе)
– Кэш для одного инстанса (например, для акторов)
– База данных для стартапа / проекта, требующего работу с большим объемом данных, но при этом нет желания платить много денег за инстанс PostgreSQL / MySQL

Решение недостатков

Нам нужны 2 вещи:

– Sync Read реплики, чтобы можно было переключиться при падении master
– WAL Streaming Backup для надежных бэкапов

Опционально, async read реплики, для чтения с задержкой или вообще CRDT для превращения ее в distributed multi-master p2p базу

И в идеале все это встраиваемое в саму sqlite, то есть встроиваемое в язык, или как sidecar процесс. Иначе, мне кажется, использование SQLite просто теряет смысл

Интересные проекты

– Pocketbase – админка, Firebaselike HTTP API, email, auth, file storage, logs и много чего другого прямо из коробки
– Turso – распределенный SQLite на Edge среде
– Electric – на стороне клиента SQLite, который синхронизируется с PostgreSQL, используя CRDT, превращающие SQLite в multi-master edge базу данных
– LiteFS – репликация SQLite базы на уровне файловой системы
– libSQL – форк SQLite, на котором построен Turso, с возможностью разворачивать сервер, реплики, автосинк WAL в S3 и так далее
– rqlite – превращение SQLite в полноценную БД с read репликами, написанная на Go
– dqlite – примерно тоже самое, что rqlite, но на С

Какое будущее у SQLite

– Во-первых, видно, что SQLite превращается в БД для Edge среды, потому что она позволяет оперировать на минимальных ресурсах

– Также, ей точно уготовано стать p2p базой (в стиле couchbase), потому что она уже проинтегрирована / просто интегрируется в любого клиента

– При добавлении встроенных Sync Read реплик позволит с большей вероятностью использовать ее в продакшен приложениях

Еще мысли

– Если мне придется сейчас разрабатывать стандартное веб-приложение для бизнеса, я бы не стал заморчиваться и воспользовался бы PostgreSQL

– Для своих проектов с удовольствием ей воспользуюсь

– Если сработает LiteFS или libSQL, то я бы серьезнее рассмотрел ее использование в рамках продакшен приложений

А, ну и после Sync Read реплик несомненно дальше нужно добавлять частничную тэговую репликацию (например, по геотэгам), после этого выделение мастера на партиции / рейнджи и получиться у нас CockroachDB Lite

Полностью со всем согласен! Использую в продакшене на критически важных участках на заводах.

По поводу rqlite, есть ещё один вариант, который мне больше зашёл

https://litestream.io

https://github.com/benbjohnson/litestream

Смысл кокроуча это все ноды активные мастер, так что сравнение не очень)

Вот я если не ошибаюсь, то создатель Litestream потом и создал LiteFS, потому что была какая-то непреодолимая проблема с первым

А получилось использовать Litestream в проде?

Ну, CRDB же мультимастер но по рейнджам: одна нода лидер одного набора рейнджей, другая другого набора, но лидер над одним и тем же рейнджем всегда один, разве нет?

Ещё нет, но скоро будет такой опыт

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

Да да, я это и имел ввиду

Правда, чтение их реплики всегда хочется скорее как у монги: чтоб можно было на каждый отдельный запрос даже указать приоритет чтения с рид / райт ноды

Не думал, что похвалю монгу...

Там в обратной совместимости с пг сделали чтение из реплики указание