DuckDB 2.0、「サーバー不要」のDBにサーバー機能が加わった

DuckDBを使ったことがある人なら、「サーバーが要らない」という触れ込みを耳にしたことがあるはずだ。インストールすればその場で動き、別にサーバープロセスを立てて待ち受ける必要がない。これがDuckDBの売りだった。ところが2026年10月21日に公開された最新版「DuckDB 2.0.0 LTS」は、まさにそのDuckDBに、自分がサーバーとして動く機能を持たせた。公式ブログを読みながら、何が変わったのかを確かめた。

DuckDBにサーバー機能が加わった

DuckDBは今まで、どうやってサーバー無しで動いてきたのか。そして2.0の「サーバー機能」とは、具体的に何なのか。

DuckDBは最初から、1つのプロセスの中だけで完結するデータベースとして作られてきた。公式ブログも「DuckDBは初日からインプロセス型のデータベースだった」と、このことを明記している。Pythonのスクリプトでduckdb.connect()と書けば、そのスクリプト自身のプロセスの中でDuckDBが動き出す。ファイルを読み込んでその場で集計でき、別のプロセスを立てて、ネットワーク越しに問い合わせるという構成は、そもそも想定されていなかった。

2.0では、この前提に手が入った。DuckDBのプロセスを「サーバー」として起動し、別のDuckDBプロセスから接続できるようにする通信の仕組み、「Quackプロトコル」が加わった。サーバー不要を看板にしてきたDuckDBが自らサーバーとして動く、という組み合わせに、自分は最初、矛盾を感じた。公式ブログによれば、Quackプロトコル自体はDuckDBのカンファレンス「DuckCon」の直前にプレビューとして公開されていたものだ。2.0ではその性能と安定性が仕上がった。サーバー側は、次の1行で待ち受けを始める。

CALL quack_serve(token = 'my_token');

接続する側は、まずATTACH文でサーバーの場所を書く。そのうえで、2.0から新しく使えるCONNECT文によって、今のセッションの接続先をそのサーバーへ切り替えられる。

ATTACH 'quack:localhost' AS qk (TOKEN 'my_token');
CONNECT qk;
SELECT * FROM events;

接続時の注意点も公式ブログは示している。

• TOKENに渡した文字列が認証に使われ、これを知らない相手はつなげない
• サーバーは既定でlocalhostだけを待ち受ける
• 外部のマシンから接続させたい場合は、TLSで終端するリバースプロキシを手前に置くことが勧められている
• allow_other_hostnameという設定で外部ホスト名を許可することもできるが、こちらはテスト用の位置づけだ

ここまでは、DuckDB同士をつなぐ話だった。

他のDBにも同じ書き方でつながる

このCONNECT文は、DuckDB同士の接続専用なのか。それとも、もっと広く使えるのか。

手元のDuckDBから、本番で動いているPostgreSQLの注文テーブルを、丸ごとコピーせずに集計したい、という場面を考える。

CONNECT文はQuackサーバーだけでなく、PostgreSQLやMySQLにも、同じ書き方で使える。

CONNECT 'postgres://localhost/mydb';
SELECT count(*) FROM orders;
DISCONNECT;

これだけ見ると、PostgreSQL側のordersテーブルを丸ごとDuckDB側へ運んでから数えているように見える。しかし公式ブログによれば、ここでは違う処理が動く。2.0で加わった新しいリモートプッシュダウンの仕組みにより、テーブルを転送する代わりに、SQLそのものがPostgreSQL側へ送られて実行される。

これまでの接続方法では、PostgreSQL側のテーブルを丸ごと転送してから、DuckDB側で絞り込む処理になっていた。ordersテーブルが数百万行あるなら、count(*)のような単純な集計のためだけに、その全行を毎回手元へ運んでいたことになる。リモートプッシュダウンは、この転送そのものを省き、集計をPostgreSQL側で済ませてから結果だけを受け取る仕組みだ。

CONNECTのあとに書くSELECT文はいつも同じ書き方で済む。変わるのは、接続先がDuckDBかPostgreSQLかMySQLかという違いだけになる。

この仕組みが向くのは、1回限りの集計より、長く動かし続けるサービスの方だ。公式ブログによれば、クライアント/サーバーという構成そのものは、以前から多くの利用者が要望していたという。トランザクション機能を備えたこの構成は、複数の利用者が同時に使うマルチテナントの運用や、稼働し続けるデプロイに向く、と公式ブログは説明している。メトリクスやログといった運用面の改善も、同じ2.0のリリースで加わった。

agent modeも正式版になった

このリリースには、サーバーモードのほかにもう一つ、見逃せない変更がある。

同じ2.0では、AIコーディングエージェント向けの「agent mode」も正式版になった。Claude CodeやCursorからDuckDBのCLIを操作すると、エージェントからの実行だと自動で見分ける機能だ。出力をコンパクトなMarkdown表に切り替え、公式の実験ではAIが読むDuckDBの出力量を59%減らしたという。2.0では-agentフラグで手動でも有効にでき、逆にエージェント側から-no-agentフラグを渡せば無効化できる、という切り替え方法も加わった。

このサイトではプレビュー公開時点の記事で、検出条件や実測の中身をすでに詳しく確認した。その記事を書いた2026年10月11日の時点では、2.0の正式リリース日は「10月21日」という暫定の表記でしか書けなかった。今回の発表で、その日付が確定したことになる。

まとめ

2.0はLTS(長期サポート)版で、公式ブログによれば少なくとも2027年10月までサポートされる。旧バージョンのサポート期限も、このリリースに合わせて動いた。

1.4系を使っている場合、今日(2026年10月26日)からおよそ3週間でサポートが切れる計算になる。2.0が長く使えるLTSとして位置づけられたこともあり、乗り換え先として2.0を検討する意味は大きい。

ただし、アップグレード前に確認しておきたい点が1つある。2.0より前のバージョンは、2.0が新しく作ったデータベースファイルを読めない。2.0自身は既存の古いファイルを問題なく読み書きできるが、逆方向は効かない。本番の環境を一気に切り替える前に、別の環境で動作を確かめてから移行するよう公式ブログは勧めている。最初のパッチリリースは2026年11月を予定しており、立ち上がったばかりの不具合の修正を待ちたい場合は、そのタイミングまで様子を見るという選択肢もある。

DuckDB 2.0で変わったのは、1つのプロセスの中で完結していたデータベースが、接続先を選べるようになったことだ。同じCONNECT文の書き方のまま、相手がDuckDBでもPostgreSQLでもMySQLでも構わない。サーバーを持たないことを売りにしてきたDuckDBが、必要なときだけサーバーとしても動く選択肢を持った、というのが2.0の実質になる。