DuckDB 2.0 LTSが公開、2027年10月まで

組み込み型の分析用データベース「DuckDB」の2.0.0 LTS（コード名「Cinnamon Teal」）が、2026年10月21日にリリースされました。DuckDBの公式ブログは、1.0が安定性と後方互換性を重視したのに対し、2.0は機能追加を中心としたリリースだと位置づけています。サポートは少なくとも2027年10月までです。

この記事の目次

QuackプロトコルでDuckDBをサーバーとして使える
PEGパーサ、トリガー、VARIANT型が標準に
非同期I/OでS3の読み込みが速くなる見込み
コーディングエージェント向けの「エージェントモード」
アップグレード前に確認したい互換性と削除項目
Quackの公開設計と、バージョン混在時のファイル作成に注意
出典

QuackプロトコルでDuckDBをサーバーとして使える

最大の変更は、1.5.3で導入されたQuackプロトコルの性能と安定性が磨かれたことです。quack_serve(token = ...)でサーバーを起動し、クライアントはATTACH 'quack:...'で接続します（クライアント側もトークンを指定します）。新しいCONNECT文は、アタッチしたリモートのデータベースへ切り替えるためのものです。PostgreSQLやMySQLにも使え、リモート側へ処理を送るpushdownオプティマイザが動きます。

設定で注意したいのは、デフォルトではlocalhostのみで待ち受ける点です。外部からの接続にはTLSを終端するリバースプロキシを置くことが推奨されており、allow_other_hostnameはテスト用とされています。CLIには-serveと-connectのオプションも追加されました。Publickeyは、別のマシン上のDuckDBに多数のクライアントから接続する構成が可能になると紹介しています。

PEGパーサ、トリガー、VARIANT型が標準に

SQLの内部も大きく変わりました。

PEGベースの新しいパーサがデフォルトになりました。1.5では任意で有効にする機能でしたが、2.0でデフォルトになりました。構文の衝突が起きにくくなり、拡張機能が新しい構文を追加しやすくなります。エラーメッセージには正確なソース位置が付きます。旧パーサはlegacy_parser拡張とSET enable_legacy_parser = true;で使えます。
トリガーはCREATE TRIGGERで、BEFORE/AFTER、行単位/文単位、REFERENCING OLD/NEW TABLE、RETURNINGなどに対応します。公式ブログには、集計テーブルをトリガーで差分更新する例が紹介されています。ただし、BEFORE ... FOR EACH ROWとUPDATE ... FOR EACH ROWの一部の組み合わせは未対応です。
VARIANT型は、半構造化データを列指向で扱う型です。共通構造を検出して分解（シュレッディング）して保存するので、圧縮と実行速度の改善が見込まれます。Parquetの読み書きまで対応し、variant_*系の関数が用意されています。

非同期I/OでS3の読み込みが速くなる見込み

Parquet、CSV、DuckDBネイティブ形式の読み込みで、非同期I/Oに対応しました。I/O層がクエリ処理から独立し、複数のリクエストを並行して発行するため、S3などのオブジェクトストレージで性能向上が見込まれます。公式ブログの本文には具体的な高速化の倍率は書かれておらず、ネットワークスループットのグラフが載っているだけなので、実際の効果は手元のデータで測る必要があります。

コーディングエージェント向けの「エージェントモード」

CLIがコーディングエージェントから実行されていることを検出すると、自動で切り替わるエージェントモードが入りました。出力をコンパクトなMarkdownの表にし、結果の切り詰めを通知し、暴走したクエリを早めに止め、エラーをJSONで報告します。クエリは、実行前に想定コストを報告します。公式ブログによれば、TPC-Hを使った実験で、モデルが読むDuckDBの出力量は59%減りました。-agentで有効化、-no-agentで無効化できます。

アップグレード前に確認したい互換性と削除項目

移行で影響が大きいのは、次の点です。

ファイルの互換性：2.0は既存のデータベースファイルを読み書きでき、そのファイルは旧バージョンでも引き続き読めます。一方、2.0より前のバージョンは、2.0で作成されたデータベースファイルを読めません。
ラムダ構文：単一矢印のx -> x + 1はデフォルトで無効になりました。SET lambda_syntax = 'enable_single_arrow';で一時的に戻せますが、2.1で削除される予定なので、Python形式のlambda x: x + 1への移行が必要です。
ICUの削除：タイムゾーン、カレンダー、照合順序を扱うICUライブラリが削除され、icu拡張が独自に実装しています。処理速度も向上したとされています。
ビルド：C++17コンパイラが必要になり、リリースビルドのデフォルトコンパイラはClangになりました（Windowsでは、主な拡張機能は引き続きMSVCです）。amalgamationビルドは非推奨です。
macOS x86_64：段階的に縮小され、2.1でサポートが終わります。

サポート期間は、2.0が少なくとも2027年10月まで、1.4が2026年11月17日までです。1.5は2027年3月までサポートが延長されています。公式ブログは、本番への移行前にシャドウ環境でのテストを勧めており、ミッションクリティカルな用途では、11月予定の最初のパッチリリースを待つ選択肢も示しています。

Quackの公開設計と、バージョン混在時のファイル作成に注意

運用面で影響が大きいのは、Quackで「ファイルを共有する組み込みDB」から「ネットワーク越しに接続されるDB」に変わる点と、2.0が新しく作るファイルの扱いです。Quackのサーバーはlocalhostでしか待ち受けないため、外部に公開するには、TLSを終端するリバースプロキシと、トークンの配布・失効の管理を利用者が用意する必要があります。ここはallow_other_hostnameで済ませないほうがよい部分です。ファイルについては、2.0で既存ファイルに書き込んでも旧バージョンで読めますが、2.0で新しく作ったファイルは1.xで開けません。そのため、CIや共有ストレージで1.4・1.5と2.0が混在する間は、新規ファイルを作る側だけを先に2.0へ上げないのが現実的な対応です。1.4のサポートが11月17日に切れる一方、1.5は2027年3月まで続くので、まず1.5にそろえ、2.0は11月のパッチを待ってシャドウ環境で試す二段階の移行が組みやすいと考えます。以上は公式ブログの記載をもとにした筆者の見方で、実際の挙動は手元の環境で確認してください。