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

DuckDBがデータ処理の第一選択である理由

2026年1月16日原文(robinlinacre.com)

概要

  • DuckDB はシンプルで高速な インプロセスSQLエンジン
  • Pythonとの親和性が高く、 データ処理の主力ツール として利用拡大
  • インストールやテストが容易 で、CI/CDにも最適
  • 多彩なSQL機能 やファイル形式対応、拡張性も魅力
  • 中規模データの分析基盤 として、従来のクラスタ構成からの移行が進行中

DuckDBの特徴と利点

  • DuckDB は、アプリケーション内で動作する オープンソースSQLエンジン
  • インプロセス型 で、SQLiteのように 別サービスの起動不要
  • 分析クエリ最適化 が強みで、大規模な結合や集約に特化
  • OLAPエンジンとして、 SQLiteやPostgresより100~1,000倍高速 な場合も
  • CSV、Parquet、JSONなど 様々なファイル形式 のバッチ処理に最適
  • コマンドラインからの CSV閲覧 など、軽量な用途にも対応

高速性とインストールの容易さ

  • 高速ベンチマーク でPolars、DataFusion、Spark、Daskと並ぶ性能
    • SparkやDaskは大規模データで競合するが、小規模ではDuckDBが優位
  • 単一バイナリ で提供、Pythonなら pip installのみで依存関係なし
  • uvと組み合わせることで、 1秒未満でPython環境構築 が可能

CI・テスト環境との親和性

  • 高速起動 ・シンプルなセットアップで CIやパイプラインテスト に最適
  • Spark等の従来エンジンより テストの手間や環境差異が大幅減少

SQL記述の快適さ

  • 素早い実行とシンプルな記法 でSQL開発がスムーズ
  • SparkやAthenaに比べ、 ローカルでの反復開発が容易
  • DuckDB UI ではオートコンプリート機能も利用可能

使いやすいSQL構文

  • EXCLUDECOLUMNS (正規表現によるカラム選択・置換)など独自拡張
  • QUALIFY やウィンドウ関数の集約修飾子もサポート
  • 関数チェーン (例:first_name.lower().trim())が可能で直感的

多様なファイル形式への高速対応

  • S3やWeb上のファイル も直接クエリ可能
    • 例:select * from read_parquet('https://raw.githubusercontent.com/plotly/datasets/master/2015_flights.parquet') limit 2;
  • CSV等の非型付きデータ にも厳格な型指定オプションあり

Python APIの利便性

  • CTEの連鎖 によるパイプライン構築が容易
  • duckdb.sql()で 各処理ステップをPython変数化 し、途中結果の確認も簡単
  • 遅延実行 でパフォーマンス低下なし、各ステップを 独立してテスト可能

ACID準拠とミドルスケール分析基盤

  • バルクデータ操作における完全なACID準拠
  • IcebergやDelta Lakeのような レイクハウスの代替候補 として注目
  • 詳細は公式ポッドキャストやドキュメント参照

高性能UDFとコミュニティ拡張

  • C++で高性能UDF開発 が可能、従来のSparkに比べて配布が容易
  • コミュニティ拡張 はINSTALLコマンド一発で導入可能
    • 例:INSTALL h3 FROM community(地理空間用インデックス)

ドキュメントの充実

  • Markdown形式で提供 され、LLMやエディタでの活用が容易
  • コードフォールディング で必要部分だけ抜粋しやすい

Splinkでの実績と開発効率

  • Splink(大規模レコードリンケージOSS)で DuckDB推奨により導入増加
  • ユーザーの問題減少・処理速度向上・開発/テスト効率化 を実現

今後注目の拡張

  • PostgreSQL Extension でPostgres DBへ直接クエリが可能
  • pg_duckdb でPostgres内にDuckDBエンジンを組み込み、
    • トランザクションと分析処理の両立が期待
  • Postgresインデックス活用やフィルタープッシュアップ等、今後の改善に期待

補足

  • 大規模クラスタ不要な時代の到来、 DuckDBの分散版 も登場
  • Sparkの複雑な設定からの解放、 中規模データ分析の新定番 としての地位向上
  • Athenaのようなプロプラエタリ環境に比べて 開発サイクルが高速

Hackerたちの意見

CSVやjson/jsonlファイルでSQLを使えるのはめっちゃいいね。もちろん、それ以上のこともできるけど、俺はそれが一番多い使い方だよ。duckdb大好き。

確かに!俺はシンプルなCSV/TSVの処理にはawkが好きだけど、複数のCSVファイルを結合したり、特定のカラムを集計したりする場合は、SQLが本当に輝くと思う。

著者の考えは基本的なデータ処理には妥当だと思うけど、それ以外の主張、例えば「ほとんどの表形式データは単一の大きなマシンで処理できるシンプルな世界に向かっている」っていうのは、かなり議論の余地があるね。データをどうピボットしたりスケールしたりするかによっては、一見「収まる」データセットでもすぐにメモリ不足になることがあるよ。著者は別の記事でも「新しいデータエンジニアリングの作業にはSQLが最初に考慮されるべき選択肢だ」と言ってるけど、これは俺の経験とは全然合わないな。複雑な分析や拡張をあまり必要としない、きれいにパースされたデータセットの範囲外ではね。

SQLが人気なのは、みんなが学んで使い始めるのが簡単だからだよね。Pythonの方が良いツールになることもあるけど、SQLがなくなることはないと思う。俺の経験では、データモデリングの面ではまだSQLが圧倒的に多いよ。ただ、データの取り込みはほとんどPythonやScalaだけどね。

著者です。「SQLが最初に考慮されるべき選択肢」とのことですが、pandasやpolarsのような他のデータフレームAPIにも確かに利点がありますし、瞬間的にはどれかがSQLより優れていると言えるかもしれません。今はPolarsが注目されていて、高品質なAPIです。ただ、エコシステムがどれかに標準化されていないのが問題で、データフレームAPIを変えるたびにパイプラインを再構築しなきゃいけないのが面倒です。データが巨大な場合はメモリ不足になることもあると思いますが、一般的に人々が処理する表形式データの大半は10GB未満で、それなら単一の大きなマシンで問題なく処理できると思います。私の経験では、Sparkが必要ないほど小さなデータセットでも使われているのをよく見ます。DuckDBは注目を集めているけど、今の時代、ノートパソコンで数GBのデータをすぐに処理できることに気づいていない人が多いみたいです。全体的には、DuckDBを最初に使うことを考えるのは良いアイデアだと思います。多くの場合、すぐに簡単に仕事をこなしてくれますからね。適切でないシナリオもたくさんありますが、始めるにはいい場所だと思います。

500GBのParquetを大きめのデスクトップ(50GB RAM)でDuckDBを動かしてるけど、スムーズで速いよ。OOMの問題はそのうち出てくるかもしれないけど、現実のユースケースの中では上位1%に入ると思う。

そうだね、私も同じく混乱してる。 >「新しいデータエンジニアリングの作業にはSQLが最初に考慮されるべき選択肢だ。堅牢で、速くて、将来にわたって使えるし、テストもできる。ちょっと気を使えば、明確で読みやすい。」(ポーラーやパンダなどと比べて)SQLは速さとは関係ないと思うけど、ポーラーよりもテストしやすい理由って何だろう?将来にわたって使えるってどういう意味?SQLの方言が壊れる変更がないってことかな?

最近はAWSで32TiBのRAMインスタンスが手に入るよ。

私の経験では、MLや可視化、先進的な分析をしたいなら、データフレームの方が良い体験ができるよ。パイプラインでデータをシャッフルするなら、SQLでもいいけどね。読みやすさは見る人によるから。私はデータフレームの方が好きだけど、ネットの一部では見ただけで吐きそうになるって言ってる人も多いね…

duckdbの好きなところ: -- .parquet、.json、.csvをサポートしてる(Spotifyのリスニング履歴が複数の.jsonファイルで来るのが面白い)。 -- glob読み込みをサポートしてるから、例えば「select * from 'tsa20*.csv'」みたいに、何百ものファイルを一つのファイルのように読み込める。 -- ファイルのスキーマが同じじゃなくても、union_by_nameがすごい。 -- .csvパーサーが優秀で、自動で型をうまく割り当ててくれる。 -- 小さい!Web Assembly版は2MB、CLIは16MB。 -- 小さいから、duckdbを直接製品に組み込める。Malloyがやってるみたいにね: https://www.malloydata.dev/ MalloyはPowerBIやTableauの技術者向けの代替品だと思ってるけど、AIがデータに対して素晴らしいクエリを書くのを助けるセマンティックモデルを使ってる。編集:Malloyはそのセマンティックな特性のおかげでSQLを書くのが10倍簡単になるよ。MalloyはSQLにトランスパイルする、TypescriptがJavascriptにトランスパイルするみたいにね。

MalloyとPRQLはめっちゃクールだね!

解凍したら32MB、圧縮すると約6MBだから、そんなに小さくはないよね。https://cdn.jsdelivr.net/npm/@duckdb/duckdb-wasm/dist/ それに、SQLiteに比べてカスタマイズが難しいから、例えばCSV用の独自のパーサーを使いたい場合は大変だよ。でも、確かに便利な機能がたくさんあるのはその通り。

Hacker Newsで議論の続きを見る