DoltLite вышел в бету: форк SQLite с Git-версионированием, построенный ИИ-агентами

DoltLite вышел в бету: форк SQLite с Git-версионированием, построенный ИИ-агентами

Проект DoltLite, форк SQLite от команды DoltHub, вышел в открытую бета-версию 0.50.0 спустя пять месяцев после запуска. DoltLite добавляет к SQLite полноценный Git-стиль контроля версий: ветки, слияния, диффы, ребейзы, cherry-pick, откаты, а также удалённые операции push/pull/clone/fetch, как с собственным удалённым сервером, так и с сервисом DoltHub в качестве бэкенда синхронизации.

Технически DoltLite оставляет нетронутым всё, что находится выше слоя B-дерева в SQLite: SQL-парсер, анализатор запросов, работу с файловой системой и тестовый набор. Сам слой B-дерева заменён на Prolly Tree, адресуемую по содержимому древовидную структуру, на которой строится версионирование во всех продуктах Dolt. Благодаря этому SQL-движок достался команде «бесплатно» вместе с SQLite, вместо того чтобы писать его с нуля поверх версионируемого хранилища, как в других продуктах Dolt.

Ключевая особенность запуска, способ разработки. Команда собрала DoltLite примерно двумя тысячами pull request'ов, сгенерированных ИИ-агентами через оркестратор агентов Gas Town, созданный Стивом Йегги (Steve Yegge). Автор поста описывает проект как проверку того, способна ли команда агентов написать движок хранения на языке C с нуля, и называет выход в бету доказательством, что способна.

Beta для DoltLite означает четыре вещи: стабильность формата хранения, совместимость по SQL с SQLite, полноценный контроль версий и производительность на уровне продакшена. До стабилизации формат менялся 12 раз, что требовало от пользователей либо оставаться на одной версии, либо вручную выгружать и заново загружать базы; текущий формат держится уже 57 релизов (свыше трёх месяцев календарного времени), и дальнейшие несовместимые изменения обещают сопровождаться поддерживаемой миграцией. По SQL-совместимости DoltLite проходит 100% из 5,8 млн запросов набора sqllogictest и 99,46% из 892 277 TCL-тестов SQLite (4809 известных расхождений, для каждого указана причина, например, таблицы в DoltLite ключуются по первичному ключу, а не по rowid, а вместо страниц используются чанки, поэтому тесты, напрямую проверяющие rowid или страницы, не проходят; тесты WAL и журнала пропускаются, так как WAL-режима и журнала-компаньона в DoltLite нет).

По производительности DoltLite даёт встраиваемую СУБД микросекундного масштаба, но с «налогом» на запись за версионирование, чтение почти на паритете с SQLite. По ночному бенчмарку в стиле sysbench: у баз в памяти чтение в DoltLite медленнее на 10%, запись, на 60%; у файловых баз чтение на паритете с SQLite, а батчевая запись медленнее на 10%. Главное отставание, на мелких автокоммитных записях: они в 3,1 раза медленнее, чем в SQLite (около 400 микросекунд против примерно 125 микросекунд на небольшом GitHub-раннере), поэтому команда рекомендует по возможности использовать батчевую запись.

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

  • DoltLite (форк SQLite от DoltHub) вышел в открытую бету версии 0.50.0 через пять месяцев после запуска
  • Добавляет к SQLite Git-стиль контроля версий: ветки, слияния, диффы, ребейзы, cherry-pick, push/pull/clone/fetch, синхронизацию через DoltHub
  • Построен примерно 2000 pull request'ами от ИИ-агентов через оркестратор Gas Town Стива Йегги
  • Проходит 100% из 5,8 млн запросов sqllogictest и 99,46% из 892 277 TCL-тестов SQLite (4809 известных расхождений с указанными причинами)
  • Чтение почти на паритете с SQLite, запись медленнее (до 3,1 раза на мелких автокоммитных записях); формат хранения стабилизировался после 12 изменений и держится уже 57 релизов

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

DoltLite показывает, что команда ИИ-агентов способна довести до продакшн-стадии не игрушечный проект, а инфраструктурный компонент, движок хранения на C, встроенный в форк SQLite. Это конкретный кейс агентного метода разработки: около 2000 pull request'ов через оркестратор Gas Town привели к рабочей бете с прошедшими тестами SQLite. Для пользователей SQLite это ещё и практический результат, Git-подобное версионирование (ветки, диффы, слияния) поверх привычной встраиваемой базы без необходимости писать SQL-движок заново.

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

Разработчикам, использующим встраиваемые базы SQLite и которым нужны версионирование, синхронизация с учётом конфликтов или полноценный откат изменений. Существующим пользователям продуктов Dolt, которым нужен более лёгкий встраиваемый вариант вместо полноценного сервера. Тем, кто следит за практикой агентной разработки инфраструктурного ПО, DoltLite здесь выступает конкретным прецедентом, а не гипотезой.

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

DoltLite доступен уже сейчас как бета версии 0.50.0. По API и поведению он ведёт себя как SQLite с добавленными функциями версионирования и командами push/pull/clone/fetch, синхронизацию можно вести через собственный удалённый сервер или через DoltHub. Есть GUI Dolt Workbench с режимом агента, позволяющим запускать ИИ-агента над своей базой и откатывать его действия через dolt_reset('--hard'). Для производительности команда рекомендует по возможности использовать батчевую запись вместо мелких автокоммитных операций, на них разрыв с SQLite наибольший (3,1 раза). Поддержка проекта, через Discord-канал #doltlite.

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

Источник, официальный блог DoltHub, пост написан от первого лица создателем проекта, то есть это самоотчёт компании о своём же продукте, а не независимая проверка. Цифры по тестовым наборам (sqllogictest, TCL-тесты SQLite) и по производительности (ночной sysbench-бенчмарк) поддаются проверке, DoltHub публикует отчёты на GitHub, но фраза о том, что отзывы «с полей» универсально положительные, это собственная формулировка команды, не подтверждённая сторонними источниками. Независимой оценки или сторонних обзоров DoltLite в статье нет.

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

Запись в DoltLite медленнее, чем в SQLite, на 10, 60% в зависимости от сценария, а на мелких автокоммитных записях, в 3,1 раза; это ограничивает применимость для нагрузок с частыми небольшими транзакциями без батчинга. Проект вышел лишь в бету, а не в финальный релиз, и до стабилизации формат хранения менялся 12 раз с несовместимыми breaking-изменениями, история подсказывает, что стабильность ещё предстоит подтвердить временем. В статье не раскрыто, как именно организовывался и проверялся человеком объём примерно в 2000 pull request'ов от агентов, уровень ревью и надзора остаётся неизвестным. Календарных дат запуска и выхода в бету в источнике нет, есть только относительные интервалы, что затрудняет независимую сверку хронологии.

«Потребовалось около 2000 pull request'ов, но выход DoltLite в бету доказывает: команда агентов действительно способна на это.»

— автор поста в блоге DoltHub