DuckDB 2.0は、インプロセス型の分析データベースであるDuckDBの次期メジャー版で、コードネームはCyanopteraです。最大の変更は、Quack拡張とCONNECT文によってDuckDB同士がネットワーク越しに接続できる「サーバーモード」が安定版に昇格する点にあります。このほかVARIANT型の強化、トリガー、非同期I/O、PEGベースの新SQLパーサー、新しいストレージ形式v2.0.0も同じ版で入る予定です。本記事では2026年10月時点の公式情報をもとに、1.5系との違い、alpha版の導入コマンド、Quackサーバーの最小構成、1.x系ファイルの移行手順を順に示します。DuckDBそのものの特徴やSQLiteとの違いはDuckDBとは？特徴・用途とSQLite・PostgreSQLとの違いを実測で解説で扱っています。
まとめ：DuckDB 2.0は10月21日予定、本番移行は2.0.1以降の検証後に判断
公式のリリースカレンダーでは、2.0.0が2026-10-21、2.0.1が2026-11-18の予定です。どちらも暫定と明記されており、延期はありえます。一方で1.5.0のサポート終了（EOL）は2026-11-01、1.4.0 LTSは2026-11-17と記載されています。1.x系に留まれる期間は、2.0の正式版から1か月もありません。
結論として、今すぐやるべきことはalpha版で既存SQLと拡張の動作を確かめることです。本番の切り替えは2.0.1を待ち、Quackサーバーを社外に公開するのはTLS終端と認可関数を用意してからにします。DuckLabsのAWS参加でライセンスが変わる心配は、公式発表を読む限り不要です。
DuckDB 2.0の変更点を1.5系と比べる：サーバー化・パーサー・ストレージ
公式のA Preview of DuckDB v2.0（2026-08-17公開）によると、1.5（2026年3月）以降のコミットは1万件を超えます。ここでは利用者側の作業に影響する変更から順に並べます。
Quack拡張とCONNECT文によるクライアント・サーバー型への転換
1.x系のDuckDBは、アプリケーションのプロセス内で動く組み込み型でした。複数のプロセスから同じファイルへ書き込むことはできず、共有したいときはファイルを配るか、MotherDuckなどの外部サービスを挟む必要がありました。
2.0ではQuack拡張がDuckDB独自のプロトコルで別のDuckDBと通信し、CONNECT文でセッションをリモート側へ向けられます。Quackは1.5.3で実験的に提供されていたもので、2.0で安定版になる予定です。CONNECTはPostgreSQLやMySQLにも使え、リモートpushdownオプティマイザがSQLを相手側で実行させるため、テーブル全体をネットワーク越しに引き込まずに済みます。
VARIANT型・トリガー・CTE内DMLなどSQL機能の追加点
VARIANT型は1.5で入った型で、行ごとに形が異なるデータを格納でき、DuckDBが共通構造を自動で分解して列として圧縮します。2.0ではストレージから直接分解を読む処理と、Parquetの分解済みVARIANTの読み書きが加わりました。既存のJSON型をVARIANTで裏打ちする計画もありますが、時期は確約されていません。
トリガーはBEFOREとAFTER、行単位と文単位の両方に対応し、REFERENCING OLD TABLEで更新前後の行をまとめて受け取れます。監査テーブルへの記録をアプリ側で書かずに済むのは大きい差です。ほかにもCTEの中でDELETE ... RETURNINGを使うパイプライン、CREATE SCHEMA finance.reportsのような入れ子スキーマ、json_setなどのJSON更新関数、類似度で上位k件を結合するNEAREST結合が追加されます。
非同期I/Oと再帰CTE書き直しで変わるクエリ性能の公式ベンチマーク値
非同期I/OはParquet、CSV、DuckDB形式の順に対応しました。公式はネットワークストレージで効果が大きく、ローカルディスクでは差が小さいと説明しています。S3上のParquetを直接読む構成ほど恩恵があると考えてよいでしょう。
数値で示されているのは次の3つです。いずれも公式の自己申告で、手元の環境での再測が前提になります。
| 対象クエリ | 1.5.4 | 2.0プレビュー | 倍率 |
|---|---|---|---|
| 再帰CTE（100万エッジ） | 4.90秒 | 0.12秒 | 約40倍 |
| タイムゾーン変換（2,500万行） | 0.24秒 | 0.11秒 | 2.2倍 |
| 照合順序deで絞込（500万行） | 0.15秒 | 0.06秒 | 2.6倍 |
再帰CTEの差はエンジンの書き直しによるものです。組織階層や部品表をSQLで展開している処理なら、2.0への移行だけで待ち時間が変わる可能性があります。
PEGパーサー・新ストレージ形式v2.0.0など互換性に響く変更点
SQLパーサーは、PostgreSQL由来のものから独自のPEGベースへ置き換わります。旧パーサーとの互換を重視して作られていますが、公式は差異を見つけたら報告するよう求めています。つまり、まったく同じ解釈になる保証はありません。
公式が破壊的変更として名指ししているのは、既定のストレージ形式がv2.0.0になることと、ラムダ構文の移行完了の2点です。タイムゾーンや照合順序の処理もICUライブラリを外して自前実装へ移りました。既存クエリはそのまま動くと説明されていますが、日付の境界値を扱う集計は2.0で結果を突き合わせておくべきです。拡張機能は新しいC APIへ移り、以後はDuckDBの版を上げても再ビルドが不要になる設計です。
1.4 LTS・1.5系・2.0のサポート期限とリリース日程の比較
リリースカレンダーの記載を表にまとめます（2026-10-10時点）。
| 版 | リリース日 | EOL | 最新パッチ |
|---|---|---|---|
| 1.4系（LTS） | 2025-09-16 | 2026-11-17 | 1.4.5 |
| 1.5系 | 2026-03-09 | 2026-11-01 | 1.5.6（2026-09-28） |
| 2.0系 | 2026-10-21予定 | 未記載 | 2.0.1は2026-11-18予定 |
1.4.0以降は1つおきの版がLTSになり、LTSのコミュニティサポートは約1年とされています。2.0がLTSかどうかはカレンダーに書かれていないため、確定するまでは「通常版」として計画を組むのが安全です。EOL後のサポートはDuckLabsが提供すると案内されています。
DuckDB 2.0 alphaをインストールしてQuackサーバーを立てる手順
正式版を待つ間に試せるのが、2026-09-02に案内されたv2.0-devのalpha版です。v2.0-cyanopteraブランチが切られて機能凍結に入っており、以後はバグ修正が中心になります。alpha版は本番向けではない点に注意してください。安定版の入れ方はDuckDBの使い方：インストールからPython・CLI・ファイル読み込みまでの実装手順にまとめています。
CLIとPythonでv2.0.0-alphaを入れて版番号を確認するコマンド
公式記事に載っているコマンドをそのまま並べます。LinuxとmacOSのCLIは次の2行です。
# Linux・macOS：alpha版のCLIを入れて版を表示
curl https://install.duckdb.org | DUCKDB_VERSION=alpha bash
~/.duckdb/cli/latest/duckdb -c "SELECT version() AS version;"
# Windows（PowerShell）
$env:DUCKDB_VERSION = "alpha"; irm https://install.duckdb.org/install.ps1 | iex
# Python：プレリリースを明示して入れる
pip install duckdb --pre --upgrade
python3 -c "import duckdb; print(duckdb.version())"公式の出力例は、CLIがv2.0.0-alpha39998、Pythonが1.6.0.dev379 (with duckdb 2.0.0-alpha39998)です。Pythonパッケージの版番号は1.6系のまま、中身のエンジンが2.0という組み合わせになっています。パッケージの版番号だけを見て1.x系と判断しないよう、duckdb.version()の括弧内まで確認し、検証用の仮想環境は本番と分けてください。
quack_serveとATTACHで別プロセスから接続するまでの最小構成
ターミナルを2つ開き、片方をサーバー、もう片方をクライアントにします。Quackのリファレンスによると既定の待ち受けはlocalhostで、ログ例のポートは9494です。
-- ターミナルA（サーバー側）：トークンを指定して待ち受ける
CALL quack_serve(
token = 'my_token'
);
-- ターミナルB（クライアント側）：接続してセッションをリモートに向ける
ATTACH 'quack:localhost' AS qk (TOKEN 'my_token');
CONNECT qk;
SELECT 42;
DISCONNECT;
-- ATTACHせずに1本だけ投げる場合
FROM quack_query('quack:localhost', 'SELECT 42');トークンは4文字以上で、省略すると起動時にランダム生成されます。停止はquack_stop(uri)です。ブラウザ内で動くDuckDBからQuackへつなぐ構成も公式ドキュメントにあり、WASM版の仕組みはDuckDB WASMとは？ブラウザでSQL分析を実行する仕組みと実装・採用判断で解説しています。
Quackを外部公開する前に確認するバインド先・TLS・認可関数
Quackのセキュリティ文書には、そのまま公開すると危ない既定値が3つ書かれています。
- localhost以外で待ち受けるには
allow_other_hostnameを明示する必要がある（既定は安全側） - サーバー自体はTLSを使わないため、nginxやCaddyなどのリバースプロキシでTLSを終端する
- 既定の認可関数はすべてのクエリを許可するため、トークンを知る相手は書き込みもできる
3つ目は見落としやすい箇所です。公式は読み取り専用にする例として、次のマクロをquack_authorization_functionに設定する方法を示しています。
CREATE MACRO read_only(sid, query) AS
regexp_matches(upper(trim(query)), '^(SELECT|FROM|WITH|EXPLAIN|DESCRIBE|SHOW)\b');
SET GLOBAL quack_authorization_function = 'read_only';正規表現による先頭語の判定なので、関数呼び出し経由の書き込みまで防げるかは環境ごとに確かめる必要があります。社外から触らせるなら、読み取り専用ユーザーを持つ通常のDBやAPIを前に置くほうが堅い構成です。
既存の1.x系データベースファイルを2.0へ移行する手順と戻し方
ストレージ形式の公式文書は、新しい版が古い版のファイルを読めること（後方互換）を目標とし、古い版が新しいファイルを読めること（前方互換）はベストエフォートとしています。2.0で書いたファイルを1.x系に戻すには、明示的な手順が要ります。
duckdb_databasesでファイルのストレージ版を確認する方法
移行前に、手元のファイルがどの形式で書かれているかを確認します。
SELECT database_name, tags
FROM duckdb_databases();公式の対応表では、ストレージ番号68が1.5系、67が1.4系、64が0.9〜1.1系です。2.0では既定がv2.0.0形式になるため、2.0で一度書き込んだファイルを1.5系のアプリが開けなくなる事態を想定しておきます。共有ストレージ上の.dbファイルを複数のバッチが読む構成では、すべての読み手を同時に上げるか、次の2つの方法で形式を揃えます。
EXPORT DATABASEとIMPORTで旧ファイルを新形式へ載せ替える
確実なのは、旧版でエクスポートし新版でインポートする方法です。公式文書の例を、1.5系と2.0系に読み替えて示します。
# 1.5系のCLIでスキーマとデータを書き出す
/older/duckdb mydata.old.db -c "EXPORT DATABASE 'tmp'"
# 2.0系のCLIで新しいファイルに読み込む
/newer/duckdb mydata.new.db -c "IMPORT DATABASE 'tmp'"元のファイルを残したまま新ファイルを作るので、切り戻しは旧ファイルに戻すだけで済みます。EXPORT DATABASEは既定でCSVとして書き出すため、大きなファイルではEXPORT DATABASE 'tmp' (FORMAT parquet)と指定して書き出し量と時間を抑えます。
STORAGE_VERSION指定で1.x系と共有できるファイルを書く手順
当面1.5系のアプリと同じファイルを共有したい場合は、ATTACH時にSTORAGE_VERSIONで「どの版から読めるべきか」を指定できます。
ATTACH 'file1.db';
ATTACH 'converted_file.db' (STORAGE_VERSION 'v1.5.0');
COPY FROM DATABASE file1 TO converted_file;この方法は1.2.0以降で使える仕組みで、新形式の圧縮などは効かなくなります。2.0のalpha段階でどの値を受け付けるかは版ごとに確かめる必要があり、過渡期の逃げ道と割り切るのが妥当です。
DuckLabsのAWS参加とMITライセンス維持が採用判断に与える影響
2.0のプレビューと同じ8月に、開発元のDuckLabsがAWSに加わると発表されました。ライセンス変更を心配して採用を止める声もありますが、公式の文面からは止める理由は見当たりません。
2026年8月26日の発表で変わる体制と変わらないMITライセンス
DuckLabs to Join AWS, Projects to Remain Open Sourceによると、DuckLabsはAWSの子会社となり、発効は9月初旬の見込みとされました。DuckDB、DuckLake、Quackとすべての拡張はMITライセンスのまま無償で提供され、非営利のDuckDB Foundationが管理を続けます。ロードマップ、ライセンス、ガバナンスに変更はないと明記されています。
変わるのは周辺です。Foundationは利害関係者の諮問委員会を2026年秋から設ける予定で、コミュニティサポートの制限も撤廃すると書かれています。ソースコードはGitHubのduckdb/duckdbで引き続き公開されています。
ベンダーロックイン懸念で見送るべきケースと見送る必要がないケース
MITライセンスは、仮に将来の版でライセンスが変わっても、公開済みの版を使い続けたり派生させたりする権利を奪いません。DuckDBを社内バッチや分析ノートブックで使うだけなら、AWS参加を理由に見送る必要はありません。
見送りを検討すべきなのは、EOL後の有償サポートをDuckLabsに頼る前提で、かつ取引先の規程上AWS以外のクラウド事業者を選ぶ必要がある場合です。サポート契約の相手がAWSグループになる点は、調達部門の審査に影響します。このケースでは、コミュニティサポート期間内に版を上げ続ける運用を自社で持つほうが現実的です。
1.x系のサポート終了が11月に重なる中で2.0へ上げる時期の判断基準
1.5系のEOLが2.0.0予定日の11日後に来る日程は、移行計画を後回しにできないことを意味します。ここでは自社の構成別に、いつ何をするかを言い切ります。
2.0.0を待たずalphaで検証すべきなのは拡張とC APIに依存する構成
spatial、iceberg、httpfsなどのコア拡張は、alpha版向けにも提供済みです。コミュニティ拡張や自作拡張は、v2.0-cyanopteraブランチに対して事前ビルドできる仕組みが用意されています。拡張に依存するパイプラインは、正式版の前に動作確認を終えておかないと、10月下旬から11月初旬の数週間で検証と移行を同時に抱えることになります。
SQLしか書いていない構成でも、日付境界を含む集計、ラムダ構文、JSON関数を使うクエリはalphaで結果を比較しておきます。公式も、どの環境でalphaがエラーになるかの報告を特に求めています。
本番の切り替えは2.0.1以降、Quackの本番公開はさらに後ろへ
本番の組み込み用途は、2.0.1（2026-11-18予定）を待って切り替えるのが妥当です。1.x系でも、1.5.0（3月9日）の2週間後に1.5.1、1.4.0（2025年9月16日）の3週間後に1.4.1が出ており、初期の不具合は最初のパッチでまとめて直る流れが続いています。1.5系を使っている場合は、EOLの11月1日から2.0.1までの約2週間半をコミュニティサポート外で動かすことになります。この期間は機能追加を止め、凍結運用で乗り切るのが現実的です。
Quackで社内に分析サーバーを立てる用途は、さらに慎重に進めます。安定版とはいえ2026年5月に公開されたばかりのプロトコルで、TLSと認可を外部の仕組みに頼る設計です。読み取り専用・社内ネットワーク限定で小さく始め、書き込みを伴う共有は運用実績を見てから広げてください。
社内分析基盤にDuckDBサーバーを置くか、DWHへ進むかの分岐点
Quackの登場で「DuckDBを共有サーバーにする」という選択肢が増えました。分析者が数名で、データがS3上のParquet数百GBまでなら、DuckDBサーバーとParquetの組み合わせで足ります。利用者が部門をまたいで数十名に増え、行レベルの権限管理や監査が要るなら、BigQueryやSnowflakeなどのDWH、もしくはIcebergを使ったレイクハウス構成へ進む段階です。後者の組み方はデータレイクハウス実装の手順6ステップで手順化しています。
どちらの構成を選ぶかは、利用者数・権限要件・保守体制の3つで決まります。一創ではデータ分析基盤構築・MLOps構築支援として、DuckDBを使った軽量な分析環境からDWH・レイクハウスへの移行設計まで受託しています。
よくある質問
DuckDB 2.0について、移行の検討段階で出やすい質問に答えます。
DuckDB 2.0の正式リリース日はいつですか？
公式のリリースカレンダーでは2.0.0が2026-10-21、最初のパッチ版2.0.1が2026-11-18の予定です。ただしカレンダーには暫定と明記されており、品質確保のために延期される場合があります。9月2日の公式記事でも「10月後半」と幅を持たせた表現でした。日付を前提に移行作業を組むなら、延期を見込んで1〜2週間の余裕を持たせてください。
1.x系で作ったデータベースファイルは2.0でそのまま開けますか？
公式は新しい版が古いファイルを読めることを目標としているため、1.5系や1.4系のファイルは2.0で開ける想定です。注意すべきは逆方向で、2.0で書き込むと既定のv2.0.0形式になり、1.x系のアプリから開けなくなる可能性があります。複数のアプリで共有しているファイルは、コピーを取ってから2.0で開き、読み手の版を揃えてください。
DuckDBはAWSに買収されて有料になりますか？
有料化の予定は示されていません。AWSに加わったのは開発会社のDuckLabsで、DuckDB本体と拡張はMITライセンスのまま非営利のDuckDB Foundationが管理を続けると公式に発表されています。EOL後の版に対するサポートは、従来どおりDuckLabsが提供する枠組みです。コミュニティの範囲で使うなら、コミュニティサポート期間内に版を上げ続ける運用が前提になります。
DuckDB 2.0はPostgreSQLの代わりにサーバーDBとして使えますか？
分析用途の共有サーバーとしては使えますが、業務システムのトランザクションDBの置き換えには向きません。DuckDBは列指向の分析エンジンで、細かな更新が大量に並行する処理はPostgreSQLの得意分野です。2.0のCONNECT文はPostgreSQLへ直接クエリを送れるので、業務DBはPostgreSQLのまま、集計だけDuckDBから投げる併用が現実的な形です。
既存のPythonやpandasのコードは2.0で書き換えが必要ですか？
多くの場合、書き換えは不要です。Pythonパッケージは1.6系の版番号で2.0エンジンを同梱する形になり、APIの呼び出し方は大きく変わりません。ただしSQLパーサーが置き換わるため、文字列で組み立てたSQLの一部が新パーサーで別の解釈になる可能性はあります。alpha版を別の仮想環境に入れ、主要なクエリの結果を1.5系と突き合わせてから切り替えてください。
関連記事
- DuckDBとは？特徴・用途とSQLite・PostgreSQLとの違いを実測で解説【1.5.6対応】：DuckDBの基本と他DBとの違い。2.0の変更点を読む前提知識
- DuckDBの使い方：インストールからPython・CLI・ファイル読み込みまでの実装手順：安定版でのインストールとParquet・CSV読み込みの基本操作
- DuckDB WASMとは？ブラウザでSQL分析を実行する仕組みと実装・採用判断：ブラウザ内でDuckDBを動かす構成とQuack接続の前提
- Polarsとは？pandasとの違い・高速化の仕組みと実務での採用判断【実装目線】：DuckDBと並んで候補に挙がるDataFrameライブラリの判断基準
- データレイクハウス実装の手順6ステップ｜アーキテクチャ選定と移行判断を実務視点で解説：DuckDBサーバーを超える規模になったときの基盤設計
