ハクソク

世界を動かす技術を、日本語で。

DuckDB 2.0がなぜ速いのか

2026年10月11日原文(motherduck.com)

概要

  • DuckDB 2.0 のアルファ版が公開され、今秋リリース予定
  • S3を使ったクエリが大幅に高速化、特にasync I/Oによる恩恵が大きい
  • 再帰CTEやVARIANT型 など、パイプライン構築者向けの実用的な新機能
  • 数値ベンチマーク や隠れた改善点も紹介
  • 実際の利用を想定した リアルな検証結果 をレポート

DuckDB 2.0の注目ポイントと実測レビュー

  • DuckDB 2.0 のアルファ版がリリース、正式版は2024年秋予定
  • パイプライン構築者・テーブル利用者 向けに、実際に役立つ機能を中心に紹介
  • 検証環境： M5ノートPCと自宅インターネット （両バージョンで同条件、数値は参考程度）

1. Async I/O：S3クエリが劇的に高速化

  • async I/O により、AWS S3上のデータ読み込みが2～3倍高速化

  • クエリやSQL文自体は 一切変更不要

  • 例：2.2GBのParquetファイル（1カラム、228M行）をS3から集計

    • DuckDB 1.5.5： 18.8秒
    • DuckDB 2.0 alpha： 7.7秒

  • 仕組みの違い

    • 1.5.5：各ワーカーが「ダウンロード→待機→デコード」を逐次実行、最大18同時ダウンロード
    • 2.0： 専用スレッドプール が先読みダウンロード、ワーカーはデコード専念、CPUとネットワークが同時稼働

  • read_ahead_depth パラメータで挙動制御（デフォルト-1で自動、0で旧バージョン互換）

    • 23個の大きなParquetファイル（13.6GB）：11.8秒→3.9秒
    • 1.7GB CSV：116秒→55秒
    • 1MB程度の小ファイル多数：効果薄（根本的なI/Oラウンドトリップがボトルネック）

  • 結論 ：S3経由のデータ分析が ノーコードで2～3倍速 に。小ファイル多数構成は非推奨。

2. 再帰CTE：深い親子データセットで圧倒的高速化

  • 再帰CTEエンジン が刷新され、グラフ探索などで最大40倍高速化

  • 典型例： 親子関係テーブル （manager/employeeやcommit/parent_id）

    • 旧バージョン：各ラウンドごとに 全テーブル再読込 （深さ×テーブルサイズ分のI/O）
    • 2.0： 一度だけ全体を読み込み、親カラムのインデックスを構築、各ラウンドは差分のみ探索

  • ベンチマーク例

    • 20,000コミットのgit履歴探索
      • DuckDB 1.5.5：1.8～16秒
      • DuckDB 2.0 alpha：0.10秒

  • ポイント

    • 深い階層構造（git履歴、データ系譜、スレッド返信、部品表など）で劇的な効果
    • 浅い階層（組織図など）では差は小さい
    • 親子テーブルはint型IDで1テーブルに集約 がおすすめ

3. VARIANT型：JSONよりも小さく速い新データ型

  • VARIANT型 が正式サポート、JSONカラムの「shredding（シュレッディング）」を自動化

  • シュレッディングとは

    • 頻出・型が一定のフィールドを 内部的にカラム化、残りはバイナリで保存
    • 例：ログやイベントデータで「type」「user.id」などが自動で分離保存

  • メリット

    • クエリ時のパース負荷軽減、 高速化＆省ストレージ
    • 構造が安定したログデータやイベントストリームで特に効果大
    • 型が混在するフィールドはバイナリ領域に残るため、 型の一貫性維持が重要

  • 注意点

    • 例：latency_msが数値と文字列で混在すると、バイナリ領域に格納されクエリ性能低下

隠れた改善点・その他

  • SQL互換性やエラーメッセージ の改善
  • 外部ファイルキャッシュ設定 でより確実なI/O制御
  • コマンドやパラメータ のデフォルト値見直し
  • コミットログ には他にも細かなパフォーマンス改善多数

まとめ：DuckDB 2.0は何が変わるのか

  • S3経由クエリの高速化 でクラウドデータ分析が現実的に
  • 深い階層データの再帰クエリ がグラフDB不要レベルに高速化
  • VARIANT型 でJSONデータの運用がより実用的・省コストに
  • パイプライン構築者やデータ分析者 にとって、 ノーコードで体感できる進化
  • 本番運用前には自身の環境で必ずベンチマーク推奨

Hackerたちの意見

すごいビジュアルだね。ちょっと余談だけど、新しいC++拡張APIは、拡張機能の開発や配布の観点からも速くなるみたいだよ。

ビジュアライゼーションは本当に好きなんだけど、文体からLLMの雰囲気を感じるな。

「ある設定がこれを動かす、...」 「コストは実際に触れる行の数に関するもので、ラウンドのサイズとは関係ない。」 みたいな感じで、仕事でこの文体を解読しようとすると頭が混乱するから、他で見るのは嫌だな。間違ってたらごめん。でも、もし間違ってないなら、OPはLLMに代わりに書かせない方がいいよ。読者の健康に悪影響だし。

└

私のマネージャーも、生成されたレポートについて似たようなことを愚痴ってたから、彼の文章を全部引っ張り出してLLMに彼のスタイルで書かせたら、今はすごく満足してるよ。自分の文章を使って同じことをやれば、気を悪くすることもないよ。

└

本当に読めたもんじゃないね。AIの要約をざっと読むのが正解なんだろうけど、そうするとビジュアライゼーションは見れないのが残念だな。

└

仕事でこの文体を解読しようとすると頭が混乱するから、他で見るのは嫌だな。これって、オンラインで他人の行動を見て無意識に再現する大衆ヒステリーみたいに聞こえる。こうやって、私たちが消費するための本当に重要で有用な情報がどんどん届くようになる。避けられないよね。だから、こういうコメントがあるせいで、何も知らない新参者が来ても無傷でいられないのは残念だ。何の実質的な価値もないコメントが、彼らが気づかないようなものを嫌いにさせる可能性があるから。あと、https://news.ycombinator.com/newsguidelines.htmlからの引用だけど、他人の作品を浅く否定するような投稿はしないでね。良い批評コメントは何かを教えてくれるから。記事やウェブサイトのフォーマット、名前の衝突、戻るボタンの不具合などの些細な不満について文句を言わないで。興味を引くほどのものじゃないから。

└

2.0のアルファリリースを試してみたけど、スロップコードの雰囲気を感じたよ。

└

少数派かもしれないけど、これからはLLMの雰囲気は感じなかったな。少なくとも気になるほどではなかった。

└

AIっぽいところはあったけど、全体的には記事はそんなに悪くなかったと思う。ただ、時々グダグダしてる感じはした。 > 「湖を1MBのParquetファイルを何千も保存するのは悪いプラクティスだし、2.0でもそれは救えない。」っていうのは、人間が書くような言い回しじゃないよね。 > 「その意味を知っているテーブルで説明するよ。」って言われたけど、そんなテーブル知らないし。あと、 > 「グラフの到達可能性で40倍の主張」ってのも、理解するのが難しい。再帰的CTEに関するセクションはあまりうまく書かれてなくて、最適化がどう行われたかも説明されてなかった。このリンクの記事が再帰的CTEの改善について説明してるよ。 https://duckdb.org/2026/08/25/how-duckdb-runs-recursive-ctes...

└

最近、Claudeから理解できないスタイルのものを何度ももらって、部分的に書き直してもらうと、元の主張が実はあまり正しくなかったって言われることが多くなってきた。これって、低いLLMの努力だけじゃなくて、低い人間の努力のサインだと思い始めてる。少ない文のプロンプトから4段以上の段落が生成されることが多い気がする（出力が長くなるほど、質が悪くなる）。各段落を一つずつ掘り下げて、読みやすくするためにプロンプトを出すと、より高い努力で深く掘り下げてくれる。

└

LLMっぽい表現が普通の人間の書き方に影響を与えてるのかな？自分は他の技術者に対してLLM的な表現をアイロニックなジョークとして使うことがあるけど、自然に入ってくることも多くなった。自分の誤字を人間らしさの数少ない残りのサインとして受け入れ始めてる...

└

もう耐えられない。Pangramを使うと、記事の文章だけで95%のAIが出てくるんだ。

…AtlasとFableが交互にそれを行き来して（ソースコードとランタイム）疑わしいボトルネックを追跡したからだよ。

Hacker Newsで議論の続きを見る