ИИтог

Lobsters завершил переход с MariaDB на SQLite

инфраструктураРедакция ИИтогSimon Willison🔥71Рейтинг ИИтог · значимость 58 · 111111/ч

Сообщество разработчиков Lobsters, агрегатор ссылок и обсуждений, по формату похожий на Hacker News, завершило многолетний переход своей базы данных с MariaDB на SQLite и признало новую архитектуру постоянной для сайта. Переезд с MariaDB планировали ещё с августа 2018 года: изначально целились в PostgreSQL, но в 2025 году решили попробовать вместо него SQLite. Финальный этап миграции прошёл в июле 2026 года, и, по словам самих разработчиков, результат оказался достаточно стабильным, чтобы считать его постоянным решением, а не временным экспериментом.

Технически Rails-приложение Lobsters теперь целиком работает на одном VPS вместо связки «сервер приложения + отдельный сервер БД». Вместо одной большой базы данные разнесены по нескольким SQLite-файлам с разной ролью: основной файл с контентом сайта весит около 3,8 ГБ, отдельная база для кеша, 1,1 ГБ, база очереди фоновых задач, 218 МБ, а база для промежуточного ПО Rack::Attack, которое блокирует и ограничивает частоту запросов от недобросовестных клиентов, 555 МБ и продолжает расти. Сам код миграции оформлен в виде запроса на слияние (PR) разработчика Thomas Dziedzic: он добавил 735 и удалил 593 строки в 30 коммитах, затронув 188 файлов, и опирался на три более ранних PR, #1705, #1871 и #1924.

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

Автор линк-блога Simon Willison, который сослался на объявление и PR с миграцией, назвал этот переход показательным кейсом: по его словам, история Lobsters, хорошее напоминание, что в 2026 году на одном-единственном сервере с SQLite можно построить вполне полноценный продакшен-сервис.

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

  • Переход Lobsters с MariaDB на SQLite планировали с августа 2018 года: сначала целились в PostgreSQL, но в 2025 году переключились на SQLite и завершили миграцию в июле 2026-го.
  • Rails-приложение Lobsters работает на одном VPS: основная база с контентом сайта весит около 3,8 ГБ, кеш, 1,1 ГБ, очередь задач, 218 МБ, а база Rack::Attack для блокировки злоупотреблений, 555 МБ и продолжает расти.
  • PR с миграцией подготовил разработчик Thomas Dziedzic: +735 и −593 строки, 30 коммитов, изменения в 188 файлах; работа опиралась на три более ранних PR, #1705, #1871 и #1924.
  • Авторы миграции сообщают, что нагрузка на процессор и память снизилась, сайт стал отзывчивее, а после отключения старого сервера с MariaDB расходы на VPS должны сократиться вдвое.
  • Автор блога Simon Willison назвал переход показательным кейсом того, что в 2026 году на одном сервере с SQLite можно построить полноценный продакшен-сервис.

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

Кейс показывает, что SQLite, обычно воспринимаемая как база для небольших или встраиваемых приложений, выдерживает нагрузку живого сообщества с многолетней историей и постоянным продакшен-трафиком. Lobsters отказался от связки «отдельный сервер БД + сервер приложения» в пользу одного VPS с несколькими SQLite-файлами под разные задачи (контент, кеш, очередь, защита от злоупотреблений) и, по словам самих разработчиков, получил более низкую нагрузку на процессор и память, более отзывчивый сайт и, после вывода старого сервера с MariaDB из эксплуатации, вдвое меньшие расходы на хостинг.

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

В первую очередь, разработчикам и администраторам небольших и средних веб-сервисов (форумов, агрегаторов ссылок, сайтов сообществ), которые обслуживают умеренный трафик и рассматривают упрощение инфраструктуры. Полезно и командам, которые годами откладывают переезд с одной СУБД на другую: кейс Lobsters даёт ориентир, сколько это может занять по объёму кода, 735 добавленных и 593 удалённых строки, 188 изменённых файлов, 30 коммитов, и сколько подготовительных PR может для этого понадобиться.

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

Из кейса Lobsters можно вынести практический приём: не хранить всё в одном файле базы данных, а разносить SQLite-файлы по ролям, основной контент отдельно от кеша, очереди фоновых задач и отдельно от модуля защиты от злоупотреблений (как Rack::Attack). Саму миграцию вели поэтапно, через несколько последовательных PR (#1705, #1871, #1924 и финальный), а не одним большим переписыванием кода, такой пошаговый подход снижает риск при переносе действующего продакшен-сервиса на новую СУБД.

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

Источник, линк-блог Simon Willison с прямой ссылкой на исходный тред обсуждения на Lobsters и на сам PR с миграцией на GitHub. В тексте приведены конкретные и легко проверяемые технические детали, номера PR, точные размеры баз данных в гигабайтах и мегабайтах, число коммитов и изменённых файлов, а не общие заявления без опоры на цифры.

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

Схема с одним VPS и несколькими SQLite-файлами означает, что весь сайт зависит от одного сервера, а значит, критична дисциплина резервного копирования. База модуля Rack::Attack, по данным авторов, всё ещё растёт (555 МБ), то есть нагрузка и объём данных на проекте ещё не стабилизировались. Наконец, сама миграция готовилась больше семи лет, с августа 2018 года, и потребовала нескольких последовательных PR: даже переход на технически более простую СУБД для зрелого продакшен-проекта редко бывает быстрым.

«SQLite прошла проверку с блеском: нагрузка на процессор снизилась, потребление памяти снизилось, сайт стал отзывчивее, по крайней мере, так кажется мне, а после отключения старого VPS с MariaDB расходы на сервер сократятся вдвое.»

— из объявления о завершении миграции на Lobsters