Автор rqlite описал 12 лет распределённого SQLite

В сентябре 2014 года автор rqlite опубликовал короткий пост о проекте. Идея была простой: взять SQLite, поставить перед ним журнал Raft и реплицировать каждую запись на кластер, чтобы потеря узла не означала потерю данных. Исходный код лёг на GitHub в те же выходные. Насколько автор может судить, это была первая открытая система, объединившая Raft и SQLite. Сегодня «распределённый SQLite», категория примерно из дюжины проектов, часть из них получила венчурные деньги, два проекта куплены. Поскольку пишущие о категории обычно начинают историю с 2021 года, автор решил записать версию, начинающуюся в 2014-м: по его словам, он был свидетелем всего этого.

Потребность была конкретной: кластерной системе, над которой автор работал в jut.io, нужно было небольшое реляционное хранилище, и вопрос, на каком узле его держать, не имел хорошего ответа. Репликация SQLite через протокол консенсуса его решала. На работе пошли другим путём, но автор продолжил строить rqlite, потому что задача общая, а решение небольшое. Первая версия использовала goraft, ту же библиотеку, что тогда применяли InfluxDB и etcd (примерно в то же время автор пришёл в InfluxDB одним из основных разработчиков). В начале 2016 года goraft заменили реализацией Raft от Hashicorp, которая используется до сих пор. Главное проектное решение принято тогда же и не менялось: rqlite, CP-система. Запись идёт через лидера, её должно подтвердить большинство, а отрезанное меньшинство отказывается принимать записи. HTTP API, уровни согласованности чтения и снимки состояния вытекают из этого решения.

Автор оговаривает предшественников и современников. Expensify годами реплицировала SQLite внутри своей инфраструктуры по Paxos-подобному протоколу и в 2016 году выпустила её как Bedrock. ActorDB, система на Erlang, где у каждого «актора» своя база SQLite, реплицируемая через Raft, появилась примерно тогда же, что и rqlite. Ни одна из них не получила широкого распространения за пределами места рождения, но обе показывают, что идея витала в воздухе. Заслуга rqlite, по словам автора, в том, что он сделал её самостоятельной, универсальной и открытой вещью, которую может запустить любой.

В 2017 году Canonical создала dqlite, чтобы дать LXD, а позже MicroK8s встроенное реплицируемое хранилище без запуска etcd. Однажды автору лично позвонил Марк Шаттлворт: они обсуждали, можно ли приспособить rqlite, но он так и не подошёл. dqlite начинался на Go и был переписан на C с собственной библиотекой Raft. По замыслу это самый близкий к rqlite проект; разница в упаковке: dqlite, библиотека, которую встраивают, rqlite, сервер, который запускают. Canonical нужна была база внутри её продуктов, автору, база рядом с чужим продуктом.

В начале 2021 года Бен Джонсон (с ним автор работал в InfluxDB) выпустил Litestream. Он вообще не использует консенсус: следит за журналом WAL в SQLite и потоком отправляет его в S3, обеспечивая аварийное восстановление для одноузловой базы почти бесплатно. Довод Джонсона: большинству приложений кластер не нужен, им хватает одной машины и способа восстановиться, если она погибнет. Автор признаёт, что он прав для очень многих приложений, и движение «SQLite достаточно» последующих лет многим обязано этому доводу. Litestream и rqlite отвечают на разные вопросы: «что, если машина умрёт?» и «что, если машина умрёт, а ждать восстановления я не могу?». Первый вопрос встречается чаще, второй, тот, с которым приходят в rqlite. В 2022 году Fly.io наняла Джонсона и выпустила LiteFS, реплицирующую SQLite на уровне файловой системы с арендами (leases) через Consul, первую попытку сделать реплицируемый SQLite функцией платформы. Litestream же, как пишет автор, повлиял на подход rqlite к WAL в версии 8.0.

В 2022 году появились два проекта с новыми подходами. cr-sqlite добавил в SQLite CRDT как расширение: несколько писателей могут расходиться и сливать изменения без лидера. Это угол AP в пространстве решений, подходящий для приложений local-first, где гарантии CP у rqlite были бы помехой. libSQL форкнул сам SQLite: ChiselStrike, позже Turso, хотела изменить то, что проект SQLite, не принимающий внешних вкладов, менять не стал бы. Поверх форка построили хостинговый сервис с репликами на периферии сети; Turso привлекла на этом венчурные деньги, а в 2026 году, по словам автора, её приобрела Supabase. Тогда же появился SQLite Cloud, хостинговый SQLite с репликацией через Raft, ближайший к исходному замыслу rqlite проект, завёрнутый в облачный сервис. Cloudflare в 2022 году анонсировала D1, SQLite как бессерверную базу внутри своей периферийной сети, и позже поместила хранилище SQLite внутрь Durable Objects. Категория, пишет автор, превратилась из «того, что запускаешь» в «то, что покупаешь».

Из двенадцати лет автор делает три вывода (с оговоркой «я думаю»). Во-первых, основа верна: SQLite как движок хранения с репликацией снаружи переизобретали как минимум восемь команд с разными потребностями и протоколами, и никто не нашёл причины бросить. Во-вторых, у пространства решений три угла, возникшие по очереди: консенсус (rqlite, dqlite), один лидер, строгая согласованность, кластер; потоковая передача (Litestream), один писатель, дешёвое восстановление, без кластера; слияние (cr-sqlite и часть движения local-first), много писателей, итоговая согласованность. Каждый верен для своего вопроса, а большинство споров, это споры пользователей о том, какой вопрос задаётся. В-третьих, деньги достались платформам: rqlite, dqlite и Litestream открыты и бесплатны, а капитал привлекли или были куплены те, кто превратил реплицируемый SQLite в сервис со счётом. Автор называет это обычной судьбой инфраструктурных идей и говорит, что не возражает, но отмечает, что идея восемь лет была открытой, прежде чем её кто-то продал. rqlite всё ещё здесь: делает то же, что в 2014-м, но заметно лучше, и остаётся выбором для тех, кому нужна отказоустойчивая реляционная база, которую можно запускать самому, полностью понимать и никому не платить.

Ключевые факты

• rqlite анонсирован в сентябре 2014 года: Raft-журнал перед SQLite, репликация каждой записи на кластер; по словам автора, это первая открытая система, объединившая Raft и SQLite.
• rqlite, CP-система: запись через лидера, подтверждение большинства, отрезанное меньшинство записи не принимает; это решение не менялось с самого начала.
• Автор выделяет три «угла» пространства решений: консенсус (rqlite, dqlite), потоковая передача WAL (Litestream) и слияние через CRDT (cr-sqlite).
• Категория выросла примерно до дюжины проектов; Turso (libSQL) привлекла венчурные деньги, а в 2026 году, по словам автора, её приобрела Supabase; Cloudflare D1 и SQLite Cloud, хостинговые платформы.
• Главный вывод автора: деньги достались платформам-сервисам, а rqlite, dqlite и Litestream остались открытыми и бесплатными; идея восемь лет была открытой, прежде чем её стали продавать.

Почему это важно

Распределённый SQLite из нишевой затеи превратился в заметную категорию инфраструктуры: около дюжины проектов, не менее восьми независимых команд, повторивших идею репликации поверх SQLite, и два приобретения. Текст, взгляд изнутри от автора одного из первых таких проектов, с хронологией, которую обычно начинают лишь с 2021 года, и с понятной классификацией подходов: консенсус, потоковая передача, слияние.

Кому это важно

Разработчикам и архитекторам, выбирающим хранилище для небольших и средних сервисов: текст помогает понять, какой вопрос решает каждый подход, аварийное восстановление одного узла, отказоустойчивый кластер или несколько писателей без лидера. Также интересен тем, кто следит за рынком инфраструктуры с открытым кодом и за тем, кто на нём зарабатывает.

Как это применить

Автор предлагает ориентироваться на вопрос, а не на моду. Нужно только восстановиться, если единственная машина погибла, по его описанию, подходит Litestream (поток WAL в S3). Нужен кластер со строгой согласованностью и нельзя ждать восстановления, rqlite (сервер, который запускают) или dqlite (встраиваемая библиотека). Нужны несколько писателей без лидера, например для local-first приложений, подход cr-sqlite на CRDT. Если нужен управляемый сервис, автор перечисляет Turso, SQLite Cloud и Cloudflare D1. Цены и условия в тексте не приводятся.

Можно ли доверять

Это личный ретроспективный текст автора rqlite, написанный от первого лица, поэтому оценки вроде «первая открытая система с Raft и SQLite» («насколько могу судить») и «деньги ушли платформам», его собственная трактовка, и автор заинтересован в проекте. Данных об использовании, загрузках или выручке проектов в тексте нет, внешних отзывов и цитат других людей тоже нет. Хронология и перечень проектов выглядят конкретно, но проверять их стоит по первоисточникам.

Риски и подводные камни

Выбор между подходами, это выбор компромиссов: CP-система вроде rqlite отказывает в записи отрезанному меньшинству, Litestream не даёт кластера и мгновенного переключения, подход на слияниях даёт лишь итоговую согласованность. Хостинговые решения превращают технологию в «то, что покупаешь», с зависимостью от поставщика; автор отмечает, что о внутреннем устройстве такие компании рассказывать не обязаны. Оценку автора о приоритете rqlite и о расстановке сил стоит читать с учётом его позиции.

«Но стоит отметить, что идея была открытым кодом восемь лет, прежде чем кто-то начал её продавать.»

— автор rqlite, «Twelve years of distributed SQLite»