Встраиваемая база отращивает сервер: что готовит DuckDB 2.0

Анонс превью DuckDB 2.0 появился 17 августа. Версии дали кодовое имя Cyanoptera, релиз запланирован на осень 2026 года. За время, прошедшее с выхода 1.5 в марте, репозиторий вобрал свыше 10 000 коммитов — и часть новшеств заставляет пересмотреть само определение проекта.

Начать стоит с серверной роли, встроенной прямо в движок. Разработчики представили протокол Quack и оператор CONNECT: запрос можно адресовать удалённой базе, в том числе PostgreSQL или MySQL, причём фильтры и проекции автоматически уезжают на исполнение той стороне. Формулировка «встраиваемая аналитическая СУБД в одном файле» после этого описывает продукт лишь частично: один процесс способен обслуживать сетевых клиентов.

Следующая по важности новость — триггеры, которых у DuckDB раньше не существовало вообще. Обещаны варианты BEFORE и AFTER, срабатывание на каждую строку (FOR EACH ROW) и на оператор целиком (FOR EACH STATEMENT), а также transition-таблицы через REFERENCING OLD/NEW TABLE. Для системы с репутацией «read-mostly движка над Parquet» это ощутимое смещение в сторону OLTP-семантики.

Обещанные показатели

Громче всего звучит результат переписанного исполнителя рекурсивных CTE. Запрос на достижимость в графе отработал так:

Выигрыш примерно сорокакратный. Параллельно проект избавился от зависимости ICU: часовые пояса, календари и правила сортировки реализованы своими силами, а база IANA ужата примерно до 45 КБ. Дистрибутив от этого похудел, а операции ускорились — перевод часовых поясов на 25 млн строк идёт в 2,2 раза быстрее, отбор с немецкой коллацией на 5 млн строк — в 2,6 раза (измерения авторов на MacBook).

Появился асинхронный ввод-вывод для Parquet, CSV и собственного формата, а к нему режимы MMAP и DIRECT_IO под локальные накопители. Хранилище получило номер версии 2.0: индексы ART перестали намертво занимать память и перешли под управление буфер-менеджера, метаданные колонок читаются лениво, компрессия строк DICT_FSST активна по умолчанию. Заявлено, что крупные проиндексированные таблицы открываются моментально, а нужные куски подтягиваются по мере обращения.

Прибавка к диалекту

• джойны NEAREST — поиск ближайших k записей;
• операции изменения данных внутри CTE: INSERT, UPDATE, DELETE, COPY;
• схемы с вложенностью: CREATE SCHEMA finance.reports;
• переменные вида $variable_name;
• правка JSON на месте: json_set, json_insert, json_replace, json_remove;
• агрегация USING KEY в рекурсивных CTE;
• стандартные FETCH и OVERLAY, уточнённое поведение MERGE.

Особняком стоит тип VARIANT. Авторы объясняют его лозунгом «вообразите быстрый JSON»: поддерживаются shredded-выполнение непосредственно из хранилища, проброс извлечения полей вниз и работа с Parquet на чтение и запись через отдельное семейство функций variant_*.

Фундаментом всему этому служит новый разборщик на PEG, сменивший унаследованный от PostgreSQL. Выгод две: расширения получают возможность добавлять собственные синтаксические конструкции, а диагностика ошибок точнее показывает проблемное место. Заодно завезли режим совместимости с чужими диалектами, скажем SET dialect_compatibility_mode = 'spark'.

Разработчикам расширений предложили стабильный C API, который генерируется из версионированного YAML-описания, и приватные репозитории расширений с подписью RSA:

CREATE EXTENSION REPOSITORY my_repo FROM 'https://extensions.example.org';

Отдельным пунктом идёт организационная новость: осенью 2026 года фонд DuckDB запускает консультативный совет из заинтересованных сторон — он будет участвовать в определении направления развития DuckDB, DuckLake и Quack. Отразится ли это на темпе и приоритетах разработки, пока непонятно: анонсирована только сама структура.

Источники

• DuckDB — официальное превью версии 2.0