Dolt 2.0 вышел с функциями, которых от версионируемой базы ждали не первый год: автоматическая сборка мусора, сжатие архивов и более аккуратная работа с хранилищем. Для команд, которые хотят обращаться с данными как с кодом, это важный сигнал: экспериментальный подход постепенно превращается в инструмент, который можно обсуждать не только на архитектурных митапах, но и в контексте продакшена.
DoltHub выпустила новую мажорную версию своей MySQL-совместимой СУБД со встроенным Git-подобным контролем версий, сообщает InfoQ. У Dolt давно был сильный концепт: ветки, merge, clone, diff и история изменений прямо на уровне таблиц и строк. Но у такого удобства была цена в виде лишних данных на диске и репутации системы, которая интереснее как идея, чем как рабочая лошадка. В Dolt 2.0 команда как раз бьет по этим слабым местам.
Ключевое изменение связано с хранением данных. Dolt использует copy-on-write-подход: промежуточные состояния транзакций сохраняются на диск, и если они не попали в коммит Dolt, то превращаются в мусор. Основатель и CEO DoltHub Тим Сен прямо объясняет проблему: особенно много такого мусора появляется при импорте данных, а лишние состояния быстро съедают диск, потому что история коммитов и так должна сохраняться. В новой версии автоматическая garbage collection включена по умолчанию. Для пользователя это означает менее ручную эксплуатацию и меньше шансов однажды обнаружить, что красивый Git-подобный workflow незаметно превратился в прожорливый склад артефактов.
Вторая важная часть релиза, тесно связанная с первой, это новый дисковый формат archives. По заявлению команды, он уменьшает занимаемое место на 30-50% за счет словарного сжатия и дедупликации. Для open source СУБД такие цифры выглядят не как косметический апдейт, а как попытка решить один из главных практических барьеров для внедрения. Пока разработчики спорят о том, насколько удобно версионировать данные в духе Git, инфраструктурные команды обычно задают более скучный, но решающий вопрос: сколько это будет стоить по диску, бэкапам и операциям ввода-вывода. Если заявленные 30-50% подтверждаются на реальных нагрузках, разговор о Dolt становится заметно менее академическим.
Отдельно DoltHub акцентирует тему производительности. По словам Тима Сена, ранние версии базы отставали от MySQL примерно в десять раз на чтении и в двадцать раз на записи. В Dolt 2.0 команда уже сравнивает себя с MySQL на sysbench и утверждает, что теперь база на 13% быстрее на записи и на 5% быстрее на чтении. Это, конечно, не повод автоматически переписывать инфраструктурные решения: любой бенчмарк живет внутри набора допущений, а sysbench не равен всей жизни production-системы. Но сам сдвиг показателен. Еще недавно Dolt воспринимался как инженерная экзотика для тех, кому очень нужен version control поверх SQL. Теперь команда пытается доказать, что за эту идею не обязательно платить двукратной или десятикратной деградацией.
В релизе есть и еще один маркер времени: бета-поддержка векторных индексов с version control через тип Vector из MariaDB. На фоне бума прикладного ИИ почти каждая база старается показать, что умеет работать не только с транзакциями и аналитикой, но и с embedding-сценариями. На этом поле Dolt выбирает понятную для себя нишу: не просто хранить вектора, а версионировать их. Команда прямо заявляет, что это единственная база, которая контролирует версии векторов. Звучит амбициозно, но пока речь именно о beta-статусе: по данным анонса, ограничения остаются в read-path, и только после их устранения функция выйдет из беты. Для русскоязычных команд, которые строят ML- и search-продукты, тут важен не только сам факт поддержки векторов, но и идея воспроизводимых экспериментов с индексами, эмбеддингами и версиями датасетов без отдельного Frankenstein-стека из таблиц, скриптов и каталогов.
Контекст у этой истории шире одного релиза. Dolt не единственный проект, который пытается принести Git-семантику в мир данных. В материале InfoQ упоминаются lakeFS и Nessie: первый решает version control для data lake, второй выступает как транзакционный каталог с Git-подобной логикой. У всех этих систем общий диагноз рынка: командам не хватает нормального управления изменениями данных, особенно когда речь идет о тестировании на продовых выборках, откатах, изолированных экспериментах и совместной работе аналитиков, платформенных инженеров и разработчиков. Исследователь и инженер Саймон Шпети, которого цитирует InfoQ, формулирует тренд жестко: Git-подобие для данных движется к статусу table stakes, то есть базового ожидания, а не экзотической опции.
На практике это означает вот что. Для разработчиков Dolt 2.0 выглядит как шаг к более нормальной DX: меньше ручной уборки, меньше боли с диском, понятнее аргументы в пользу пилота. Для бизнеса и продуктовых команд интерес в другом: версионируемая база обещает упростить аудит изменений, тестирование миграций, безопасные эксперименты с данными и более быстрые откаты. Для IT-директоров и платформенных команд вопрос пока остается приземленным: насколько все это стабильно под реальной нагрузкой, как ведет себя репликация, что с операционной сложностью и достаточно ли зрел инструмент за пределами демо и бенчмарков. Тут важно помнить и про вторую ветку проекта: DoltgreSQL, PostgreSQL-совместимая версия на том же storage engine, все еще находится в бете. Иными словами, история уже не выглядит игрушкой, но до статуса безоговорочного корпоративного стандарта путь еще не пройден.
Главный интригующий момент в этой новости не в том, что еще одна база научилась сжимать данные или говорить про векторы. Интереснее другое: DoltHub последовательно превращает красивую идею «Git для таблиц» в историю про стоимость хранения, эксплуатацию и производительность, то есть в язык, на котором решения действительно покупают и внедряют. Если следующий этап подтвердит эти обещания в живых инсталляциях, рынок данных получит не просто необычную СУБД, а еще один аргумент в пользу того, что управление изменениями должно становиться встроенным свойством хранилища, а не самодельной надстройкой. Подробности релиза и цитаты команды можно сверить в материале .