Протокол DuckDB Quack

Анонс Quack от DuckDB за май 2026 года - нового клиент-серверного протокола на базе HTTP, который позволяет нескольким экземплярам DuckDB одновременно изменять одну и ту же базу данных. Доступен в v1.5.2 (core_nightly), релиз в production запланирован в DuckDB v2.0 осенью 2026 года. Команда DuckDB описывает это как решение переступить через себя ("biting the bullet") после долгих лет отказа от добавления wire-протокола. Масштаб обходных путей, которые сообщество городило ради прикручивания клиент-серверной архитектуры к DuckDB, убедил их: потребность пользователей настолько сильна, что реализовать протокол самим - меньшее зло, чем допустить фрагментацию экосистемы между протоколом MotherDuck, Arrow Flight SQL от GizmoSQL и самодельными RPC-слоями.

Как это работает

Два экземпляра DuckDB загружают расширение quack. Один вызывает quack_serve(...), а второй подключает его через ATTACH как удалённую базу:

-- Server
INSTALL quack FROM core_nightly;
LOAD quack;
CALL quack_serve('quack:localhost', token => 'super_secret');
CREATE TABLE hello AS FROM VALUES ('world') v(s);

-- Client
INSTALL quack FROM core_nightly;
LOAD quack;
CREATE SECRET (TYPE quack, TOKEN 'super_secret');
ATTACH 'quack:localhost' AS remote;
FROM remote.hello;       -- 'world'

Таблицы на удалённой стороне доступны как remote.table. Команда CREATE TABLE remote.t AS ... передаёт данные в обратном направлении. Для сложных запросов remote.query('SELECT s FROM hello') отправляет на сервер всю строку запроса целиком.

Архитектурные решения протокола

• На базе HTTP. Quack работает поверх обычного HTTP. Логика команды DuckDB: HTTP повсеместно поддерживается балансировщиками нагрузки, прокси авторизации, файрволами, IDS, и главное - DuckDB-Wasm в браузере умеет работать с Quack нативно. MIME-тип - application/duckdb, используется внутренняя сериализация DuckDB (та же, что и в WAL).
• Запрос/ответ, управление на стороне клиента. Последующие выборки для больших наборов результатов могут выполняться параллельно в несколько потоков.
• Один round-trip на запрос. Это принципиальное архитектурное отличие от Arrow Flight SQL, которому всегда требуется два (CommandStatementQuery + DoGet).
• Порт по умолчанию 9494 - год выпуска Netscape Navigator.
• Аутентификация. Сервер при запуске генерирует случайный токен, который клиент обязан передать; callback аутентификации можно переопределить прямо из SQL (LDAP, файл, бросок кубика). Callback авторизации по умолчанию разрешает всё (yes to everything), но его тоже можно заменить. Оба callback'а могут быть обычными SQL-макросами - реализация аутентификации через SQL выглядит необычным решением.
• TLS. По умолчанию выключен для localhost - позиция команды DuckDB: "не стоит городить SSL-инфраструктуру только ради того, чтобы говорить с самим собой". Для внешних подключений SSL считается включённым по умолчанию. Рекомендуемый вариант развёртывания - nginx на входе с терминейшеном Let's Encrypt; в документации разобран пошагово.
• Привязка по умолчанию: localhost. Quack слушает только loopback-интерфейс, если явно не указано иное.

Бенчмарки

Одна зона доступности (AZ) AWS m8g.2xlarge (8 vCPU, 32 GB, до 15 Gbps), ping ~0.28 мс. Сравнение: Quack против Arrow Flight SQL (через GizmoSQL, использующий DuckDB под капотом) и PostgreSQL.

Массовая передача данных - TPC-H lineitem, медиана 5 запусков:

60 млн строк (~76 GB CSV) менее чем за 5 секунд. Примерно в 3 раза быстрее Arrow Flight SQL и в 32 раза быстрее Postgres на масштабе. Postgres читает в один поток, тогда как Quack и Arrow распараллеливают нагрузку.

Мелкие записи - single-row INSERT, 5-секундное окно, медиана 5 запусков:

Quack масштабируется лучше Postgres вплоть до 8 потоков, после чего упирается в потолок параллельных вставок самой DuckDB - дальше вперёд вырывается Postgres. Команда DuckDB отмечает это как известное ограничение, над которым предстоит работать. Arrow Flight на всём протяжении выдаёт примерно половину показателей Postgres: сказывается ограничение в два round-trip'а.

Почему не Arrow Flight SQL

В статье этот вопрос разбирается напрямую. Arrow / ADBC - это API обмена данными вроде прежних ODBC / JDBC: они полезны для передачи данных между системами, но внутренние структуры DuckDB близки к Arrow, а не идентичны им. Зависимость от формата, который ты не контролируешь, связывает руки в развитии системы. Две конкретные причины:

• Свобода контроля над форматом: добавление нового типа данных или сообщения протокола в Quack можно выпустить в тот же день; Arrow Flight потребовал бы согласования спецификации.
• Обязательные два round-trip'а (CommandStatementQuery + DoGet): это нормально для тяжёлых аналитических запросов, но плохо для мелких записей в сетях с высокими задержками. Quack выполняет запрос и получение результата за один round-trip для небольших запросов.

Место в общей картине

• Встраиваемые (in-process) СУБД получают wire-протоколы - та же эволюция, что у SQLite, столкнувшейся с группой пользователей, которым нужна координация записи между процессами, с той разницей, что DuckDB реализовала это из коробки. Это траектория, противоположная истории с амбициями Redis: Redis начинался как сервер ключей и значений с wire-протоколом во главе угла и обрастал ненужными возможностями; DuckDB начиналась как встраиваемая база и добавила wire-протокол, потому что зоопарк костылей стал больше, чем заняла бы реализация самого протокола.
• Проектирование протоколов баз данных - Quack служит чистейшим контрпримером к тезису "используйте готовый стандарт". Опубликованные аргументы команды DuckDB служат хорошим ориентиром для похожих решений: мы не позволим формату, который не контролируем, определять наши промежуточные представления запросов, даже ценой создания очередного нового протокола.
• HTTP повсюду - Quack даёт ещё одно подтверждение тому, что в 2026 году создание нового TCP-протокола не поверх HTTP выглядит странным выбором. Поддержка Wasm в браузере - лишь часть причин; остальное - развитая экосистема аутентификации и проксирования.
• Параллельная запись несколькими клиентами в общее хранилище - альтернативы в вики: ursa-kafka-storage (Kafka на базе S3), ingodb (самотрансформирующееся LSM), lsm-trees-nosql (LSM как удобная основа для записи). Quack превращает эту задачу в узкое место на одном сервере вместо распределённого лога; компромиссы здесь иные.

Дальнейшие планы (из анонса)

• Интеграция с DuckLake, чтобы сервер DuckDB мог выступать удалённым каталогом DuckLake (существенный выигрыш в производительности за счёт инлайнинга).
• Доработка к релизу v2.0 осенью 2026 года; автоматическая установка и загрузка (auto-install / auto-load).
• Новый парсер (new PEG-based parser) для улучшения синтаксиса при обращении к удалённым SQL-базам.
• Преодоление потолка параллельной вставки в 8 потоков внутри самой DuckDB.
• Extension API, чтобы расширения DuckDB могли добавлять собственные сообщения протокола и обработчики.
• Протокол репликации поверх Quack - кластеры с репликами для чтения.

В благодарностях анонса упомянуты Boaz Leskes (MotherDuck) за обмен опытом создания протокола MotherDuck и Philip Moore (GizmoSQL) за доказательство жизнеспособности клиент-серверной DuckDB.