オープンソースの高速 OLAP データベース DuckDB に対し、複数のインスタンスを相互接続するための新しいプロトコル「Quack」が2026年5月12日に発表されました。これまで埋め込み利用が中心であった DuckDB を、認証認可と複数ライターを備えたクライアント／サーバ DBMS として扱えるようにする試みです。本記事では Quack の設計思想、性能、立ち上げ手順、そして DuckLake との関係までを整理し、データ基盤に取り込む際の判断材料を一通り押さえます。
Quack とは何か ― DuckDB がクライアント／サーバ DBMS になる
Quack は DuckDB のコアチームが開発した RPC プロトコルで、ある DuckDB インスタンスをサーバとし、他の DuckDB インスタンスからクライアントとして接続するための仕組みです。サーバとクライアントが同じ DuckDB であるため、リモートのテーブルやビューを ATTACH でローカルに見立てて扱えるのが特徴です。
従来の DuckDB は単一プロセス内で完結する利用が前提でした。ファイル単位での並列読み込みは可能でしたが、複数プロセスから同じデータベースに同時に書き込む構成は実用的ではありません。Quack はこの制約を取り除き、複数のクライアントから同時に読み書きできる構成を、追加ミドルウェアなしで実現します。
配布形態は拡張機能で、ライセンスは MIT です。INSTALL quack FROM core_nightly; でインストールでき、すでに DuckDB v1.5.2 に対してベータ版として提供されています。コアチームは2026年秋にリリース予定の DuckDB v2.0 で正式版とする計画を示しており、それまでの間は破壊的変更の可能性を前提として位置付けられています。
なぜ HTTP/2 なのか ― 設計思想とアーキテクチャ
Quack の通信路は HTTP/2 です。Postgres ワイヤープロトコルや独自バイナリではなく、あえて HTTP に乗せた理由は実運用面の取り回しにあります。既存のロードバランサ、リバースプロキシ、API ゲートウェイ、ファイアウォール越え、CDN などの資産をそのまま流用できるためです。さらに DuckDB-Wasm 配布版もネイティブに Quack を喋れるため、ブラウザで動作する DuckDB から EC2 上の DuckDB サーバへ直接接続するといった構成も成立します。
シリアライズには DuckDB 内部の Write-Ahead Log と同じシリアライザを採用しています。Arrow や Parquet を中継させる方式と比べてフォーマット変換が不要になり、ネスト型、decimal、interval といった複雑な型もロスレスのまま転送できます。1 クエリで往復が 1 回に収まる設計のため、レイテンシ感度の高いワークロードにも適しています。
サードパーティ実装である Airport 拡張（Arrow Flight ベース）とは異なり、Quack は DuckDB コアチームによるクリーンスレート実装である点も明示されています。プロトコル進化の主導権が DuckDB 本体側にあるため、内部最適化や新機能との結合が早い段階で進みやすい構造です。
ベンチマーク ― 6000万行を5秒未満、PostgreSQL と Arrow Flight を凌駕
公式ブログのベンチマークは、Quack の性格をよく表しています。バルク転送では 6,000 万行（CSV 換算 76 GB）を約 4.94 秒で転送しました。同条件で Arrow Flight SQL は 17.40 秒、PostgreSQL は 158.37 秒と報告されており、巨大な分析データを動かす用途で大きな差が出ます。
細かなトランザクションを多数流す系のテストでは、1 スレッドで 1,038 tx/s、8 スレッドで 5,434 tx/s に達し、同条件の PostgreSQL を上回ったとされています。8 スレッドを超える領域では DuckDB 本体側の同時挿入制約により頭打ちになる点が既知の課題として共有されており、こちらは今後の改善対象です。
OLAP 由来の DuckDB がトランザクション性能でも一定水準に届くことが示された意味は小さくありません。バッチでも準同期の書き込みでも、Quack 経由で 1 台のサーバに集約する構成が現実解になり得ます。
サーバ／クライアントの立ち上げ方とセキュリティ
Quack の導入は SQL だけで完結します。サーバ側、クライアント側いずれも、まず拡張をインストールしてロードします。
-- 共通
INSTALL quack FROM core_nightly;
-- サーバ
LOAD quack;
CALL quack_serve('quack:localhost', token => 'super_secret');
CREATE TABLE hello AS FROM VALUES ('world') v(s);
-- クライアント
LOAD quack;
CREATE SECRET (TYPE quack, TOKEN 'super_secret');
ATTACH 'quack:localhost' AS remote;
FROM remote.hello;
CREATE TABLE remote.hello2 AS FROM VALUES ('world2') v(s);
認証はトークン方式で、サーバ起動時に生成したシークレットをクライアントに配布します。既定では localhost にバインドし SSL も無効である点には注意が必要です。インターネット経由で公開する場合は、nginx などのリバースプロキシで SSL 終端と必要なアクセス制御を行う構成が推奨されています。HTTP/2 上に乗っているため、既存の WAF やゲートウェイによる保護をそのまま重ねられる点が運用設計を楽にします。
DuckLake との関係と v2.0 へのロードマップ
Quack はオブジェクトストレージ上のテーブルフォーマット DuckLake とも組み合わせが想定されています。DuckDB は DuckLake のカタログサーバとして動作できるため、Quack 越しに DuckDB サーバへ接続することで、ペタバイト級の DuckLake データを共有カタログ経由で扱う構成が描けます。役割分担を整理すると、Quack は DuckDB プロセス間の通信を担い、ストレージは DuckDB のネイティブ形式で〜数 TB 規模、DuckLake はオブジェクトストレージで巨大データセットを担うという棲み分けになります。
v2.0 で正式版になるタイミングでは、DuckLake カタログとしての Quack 統合が公式に位置付けられる予定です。分散クエリ処理や MotherDuck の dual execution に相当する協調実行は対象外であり、あくまで「複数の DuckDB を素直につなぐ」プロトコルである点は押さえておく必要があります。
現場での適用余地と注意点
Quack が刺さる典型シナリオは、複数のクライアント DuckDB から 1 台の集約サーバへ書き戻したいケース、分析ワーカーを横並びで増やしてリモートテーブルに同時アクセスしたいケース、そしてエッジで動かす DuckDB-Wasm から中央サーバの DuckDB に直接読み書きしたいケースです。Postgres を中央 RDB として置く構成と比べ、データ型のロスレス保持と OLAP 向けの転送性能を両立できる点が強みになります。
一方で v1.5.2 ベータの段階であり、本番投入は v2.0 正式版を待つのが妥当です。認証はトークン 1 段階で、ロール／行レベルの細粒度制御は DuckDB 側の機能やリバースプロキシでの補強が前提になります。同時書き込みのスループットも 8 スレッド付近で天井がある点を踏まえ、ワークロード設計はベンチマークで早めに当たりを付けておくと安心です。
「埋め込み高速 OLAP」という DuckDB の立ち位置を維持したまま、共有サーバとしての顔を新しく獲得する Quack は、DuckDB を中核に据えたデータ基盤の選択肢を一段広げる動きです。秋の v2.0 で正式版が出るまでに、自社のユースケースで小さくプロトタイピングしておくと、リリース後の即時投入につなげやすいでしょう。
