DuckDB показал протокол DuckDB Quack — удаленный HTTP-протокол, который позволяет нескольким экземплярам DuckDB работать с одной и той же базой по сети. Для проекта, который долго жил в роли быстрой встроенной аналитической СУБД «рядом с приложением», это заметный разворот: теперь разговор идет не только про локальные ноутбуки и ETL-скрипты, но и про многопользовательскую аналитику, общие датасеты и более внятный путь в прод.
О новинке сообщает InfoQ. По описанию команды DuckDB, Quack дает нескольким приложениям одновременный доступ к одной базе через обычные HTTP-соединения и использует нативный формат данных DuckDB, а не внешний промежуточный слой. Разработчики утверждают, что при передаче больших наборов данных такой подход примерно в 3,5 раза быстрее Arrow Flight и заметно быстрее PostgreSQL, а для маленьких запросов выигрывает еще и за счет одного сетевого раунда: запрос уходит и результат возвращается без лишней болтовни между клиентом и сервером.
Это важно не только из-за красивого названия. DuckDB исторически сравнивали со SQLite: легкая in-process СУБД, которую можно встроить в приложение без отдельного серверного контура. Именно эта простота и сделала DuckDB любимцем аналитиков, дата-инженеров и разработчиков, которым нужно быстро гонять SQL по Parquet, CSV, объектному хранилищу или локальным файлам. Но у такой модели был понятный потолок: как только одной и той же базой хотят пользоваться несколько людей или сервисов одновременно, магия локальности заканчивается и начинается подбор обходных путей. Протокол DuckDB Quack как раз закрывает этот неудобный зазор между «удобно у себя на машине» и «нужно разделить доступ без миграции на более тяжелую серверную систему».
Команда DuckDB отдельно объяснила, почему не пошла по пути Arrow Flight SQL, уже существующего протокола для работы с SQL-СУБД поверх Arrow и Flight RPC. Причина довольно прямолинейная: разработчики захотели полностью контролировать и то, как передаются данные, и то, как дальше будет развиваться сам протокол. Формулировка почти программная: в системах данных, по их мнению, трудно быстро двигаться вперед, если ключевые форматы и ограничения задаются снаружи. Для open source-проекта с сильной инженерной культурой это ожидаемая позиция, хотя в более корпоративной среде такой выбор сразу вызовет привычный вопрос про совместимость, экосистему и цену собственного стандарта.
Контекст тут шире одного релиза. За последние годы рынок аналитических движков все активнее смещался в сторону архитектур, где данные лежат не в монолитной СУБД, а в объектных хранилищах, дата-лейках и открытых форматах вроде Parquet. DuckDB органично встроился в этот ландшафт как удобный локальный «движок для чтения и расчета». Но как только компании пытаются строить на нем общие внутренние сервисы, витрины или браузерные интерфейсы, всплывает старый упрек: мол, это прекрасный инструмент, пока не нужен многопользовательский сценарий. Quack фактически отвечает именно на этот тезис. В самой DuckDB уже говорят, что протокол будет интегрирован в DuckLake, чтобы DuckDB мог выступать удаленно доступным catalog-сервером. Иначе говоря, проект двигается не от своей встраиваемой природы, а поверх нее: локальный движок остается, но вокруг него появляется сетевая координация.
Реакция сообщества, если верить InfoQ, оказалась в целом позитивной и довольно приземленной, без лишней теологии про «будущее аналитики». Управляющий партнер Lattice Engineering Райан Гловер назвал анонс важным шагом для внутренних фреймворков приложений и прямо связал его с проблемой горизонтального масштабирования. На Reddit один из пользователей заметил, что возможность поднять DuckDB на сервере и обращаться к нему удаленно «как к нормальной базе» станет большим разблокирующим фактором. Отдельно на эту тему высказался и Мехди Уазза из MotherDuck: по его оценке, разговор в духе «у DuckDB нет multi-writer support» уже выглядит слишком упрощенным, потому что вариантов организации совместной работы становится больше. Тут есть нюанс: Quack пока не превращает DuckDB в классический OLTP-сервер и не отменяет архитектурные компромиссы. Но сам набор сценариев заметно расширяет.
Для разработчиков и команд это означает вполне конкретные вещи. Во-первых, можно проще собирать внутренние аналитические сервисы там, где раньше приходилось выбирать между локальной скоростью DuckDB и сетевой природой PostgreSQL или более тяжелых MPP-решений. Во-вторых, открывается аккуратный путь к shared analytics: один датасет, несколько клиентов, стандартный HTTP, привычный SQL и меньше клея между компонентами. В-третьих, интереснее становятся сценарии на стыке дата-инженерии и AI, где нужно быстро прокидывать запросы между ноутбуками, сервисами, браузером и удаленным хранилищем, не раздувая инфраструктуру раньше времени. Не случайно в отраслевых комментариях рядом с Quack уже упоминают DuckLake, объектное хранилище, Parquet и векторные базы: связка выглядит не модной, а утилитарной.
При этом релиз нельзя воспринимать как финальную точку. Для работы нового протокола сейчас требуется расширение Quack на обеих сторонах, а поддержка уже доступна в DuckDB 1.5.3 как автоподгружаемое core-расширение и как каталог DuckLake. Команда также говорит о планах довести Quack до production-ready состояния вместе с DuckDB 2.0 позже в 2026 году. В дорожной карте фигурируют улучшение производительности, лучшая поддержка удаленных баз, более высокая транзакционная пропускная способность, настраиваемые расширения протокола и репликация. То есть в сухом остатке перед нами не просто новая кнопка, а задел на то, чтобы DuckDB чаще появлялся в архитектурах, где раньше его уважали, но не вполне пускали за взрослый стол.
Главный вопрос теперь не в том, сможет ли DuckDB остаться легким после выхода в сеть, а в том, где для него пройдет граница между удобным аналитическим движком и полноценной платформой для совместной работы с данными. Если команда удержит простоту развертывания и действительно доведет протокол DuckDB Quack до заявленных характеристик, рынок получит редкую вещь: не очередную «универсальную платформу», а инструмент, который решает конкретную старую боль без обязательного инфраструктурного переезда.