2026年5月12日、サンフランシスコで開催されたAI Council 2026において、DuckDB Labs CEOのHannes Mühleisen氏が、新しいクライアント・サーバープロトコル「Quack」を発表した。
発表前は「Super-Secret Next Big Thing for DuckDB」(DuckDBの極秘の次の大きな一手)として予告されており、DuckDB Labs自身がQuackを重要な節目と位置づけていることがうかがえる。
この「極秘の大きな一手」を楽しみにしていたが、その正体がクライアント・サーバープロトコルだと分かったとき、私は最初は腑に落ちない点が2つあった。
- DBMSの分類において、「インプロセス」対「クライアント・サーバー」の対立があって、インプロセス型のDuckDBではそもそもクライアント・サーバープロトコルがどう成り立つのか（一見、矛盾しているように聞こえる）
- なぜプロトコルだけで「極秘の大きな一手」になるのか（プロトコル自体はクエリエンジンの一部ではないのに）
本記事では、この2点を整理する。私自身がQuackの意義を理解するためのメモである。同時に、Quackをめぐって今後面白い展開があり得ることも述べたい。
もちろん、具体的なコード例やドキュメントなどの一次情報は公式ページを参照。本記事では、あくまで私が面白いと感じたポイントやその解釈を整理していく。
インプロセスDBMSはどうやってクライアント・サーバーDBMSになるのか
DuckDBはインプロセス型のDBMSだ。しかし、DuckDBを実行しているプロセスを長時間実行1（long-running process）させ、Webサーバー機能を持たせれば、クライアント・サーバー型DBMSの「サーバー側」が出来上がる。
もちろん、サーバー側が存在するだけでは意味がない。あらかじめ合意されたプロトコルに基づいて、クライアントがサーバーにリクエストを送る必要がある。
元々の意味は、クライアント（client）= 顧客、サーバー（server）= 接客係だ。
「プロトコル(protocol)」は「協定」を意味する。つまり、「こういう形式でやりとりをする」という事前の取り決めのことだ。
Quackは、DuckDBを実行している一つのプロセスをクライアント、もう一つのプロセスをサーバーとして振る舞わせ、両者がネットワーク越しに会話できるようにするためのプロトコルである。
「Quack」は、英語でアヒルの鳴き声を表す。DuckDBインスタンス同士が会話するプロトコルなので、Quackと名付けられた、というわけだ。
そうすることで、DuckDBをクライアント・サーバー型DBMSにするのだ。これが、Quackプロトコルとquack拡張機能が実現していることである。
この見方に立てば、DBMSにおける「クライアント・サーバーモデル」と「インプロセス」という二分法は、本質的に二者択一の制約ではなく、意図的なアーキテクチャ上の選択にすぎない。
QuackでDuckDBのエコシステムのユースケースが広がる
DuckDBは単体で非常に優秀なクエリエンジンだが、これまでは、同時に並行して読み書きができる一元化されたSSOT（単一の真実の源）として、そのまま使うことは困難だった。
プロトコルを用いてDuckDBをクライアント・サーバー型DBMSにするアプローチ自体は、これが初めてではない。例えば、MotherDuck（独自のプロプライエタリなプロトコル）や、GizmoSQL（Apache Arrow Flight SQLプロトコルを利用したサードパーティ実装）などがすでに存在する。
比べると、Quackはファーストパーティによるネイティブ実装であり、MITライセンスのオープンソースとして提供される。
これにより、例えば以下のような面白い可能性が生まれる。
-
手軽なセルフホストのデータウェアハウスの構築と運用
管理すべきクラスター自体が存在しないため、分散クラスターを管理するようなインフラの複雑さはない。 -
既存のエコシステムのシームレスな統合
インプロセス型DBMSとしてのDuckDBとすでに動作するものであれば、この一元化されたデータウェアハウスでも動作する。
既存のインプロセス型DuckDBと統合されているものを挙げてみる。
-
dbt(dbt-duckdb) や Apache Superset といったツール - ライブラリとしてStreamlitやText-to-SQLのエージェントと組み合わせて使う
- 主要なサーバーサイド言語で、DuckDBのライブラリが提供されている
- WebAssembly（Wasm）を利用することで、DuckDBはブラウザ上でも直接動作する
Quackのクライアントもまた一つのDuckDBインスタンスであり、インプロセスのDuckDBで動いていたものは、原理的にQuack越しのリモートDuckDBに対しても動く。DuckDBのエコシステムは、インプロセス型として既にかなり充実しており、Quackによってより広いユースケースで使えるようになる。
アプリケーションサーバーなしの、純粋なブラウザベースアプリケーション
QuackはHTTPで動く。そしてDuckDBは、WebAssembly版（DuckDB-Wasm）によってブラウザ上でも動く。この二つを組み合わせると、アプリケーションサーバーを介さずに、ブラウザが直接DuckDBサーバーと会話できる。例えば、バックエンドを持たないSPAダッシュボードは可能だ。
「アプリケーションサーバーを省く」というアーキテクチャについては、「やるべきか」と「やれるか」の二つの問いがある。前者はさておき、後者について言えば、すべてのDBMSのクライアント・サーバープロトコルが、ブラウザから動くわけではない。ブラウザは、任意のTCP接続を開くことを許していないので、TCPベースの独自バイナリプロトコルで動く伝統的なDBMS（PostgreSQLなど）に、ブラウザから直接接続することはできない。
その他
-
REPL自体がすでに長時間実行されているDuckDB CLIを使うか、あるいはサーバー側をセットアップして永久にスリープするような簡単なスクリプトを書けば、プロセスを長時間実行させ続ける。 ↩