- DuckDB は、単一マシン上で大規模なテーブルデータを高速かつシンプルに処理できる オープンソースSQLエンジン であり、近年はデータエンジニアリングで広く使われている
- インストールが簡単 で依存関係がなく、Python 環境で即座に実行できるため、CI・テスト自動化 に適している
- 分析クエリ最適化 により、SQLite や Postgres より最大 1,000 倍高速な性能を示し、さまざまなファイル形式（
csv, parquet, json）を直接クエリできる
- 親しみやすいSQL構文（
EXCLUDE, COLUMNS, QUALIFY, 関数チェイニングなど）と Python API により、複雑なパイプラインを効率よく開発できる
- ACID 準拠、高性能 UDF、PostgreSQL 統合拡張 などにより、中規模データ向けの レイクハウス代替 として台頭している
DuckDB 概要
- DuckDB は 分析クエリ最適化 に重点を置いた インプロセスSQLエンジン
- 別途サーバーなしでアプリケーション内部で実行され、Postgres のような外部サービスを必要としない
- 大量の結合・集計演算に特化しており、トランザクション中心のエンジン（OLTP）より最大 100〜1,000 倍高速 な性能を提供する
- 主なユースケースは、
csv, parquet, json などの大容量ファイルをディスクから直接読み込んで 一括処理（batch processing） すること
- コマンドラインから簡単に CSV ファイルを参照するなど、軽量なデータ探索 にも活用できる
主な特徴
-
速度
- DuckDB は 最速クラスのオープンソースデータ処理エンジンの1つ であり、ベンチマークでも上位を維持している
- Polars、DataFusion、Spark、Dask などとの比較では、小規模データでは DuckDB が優位 であり、大規模データでは Spark・Dask も競争力がある
-
簡単なインストールと無依存
- DuckDB は 単一の事前コンパイル済みバイナリ として提供され、Python では
pip install duckdb ですぐにインストールできる
- 依存関係がない ため、Spark などの大規模フレームワークと比べてインストールが非常に簡単
uv と組み合わせれば 1秒以内で Python 環境を構築 できる
-
CI とテスト
- 高速な起動時間と軽量性 により、データパイプラインの CI・テスト環境 に適している
- 過去の Spark ベースのテストは遅く複雑だったが、DuckDB は 環境設定の単純化 と 本番環境との一貫性維持 がしやすい
-
SQL 作成体験
- DuckDB は SQL の記述と構文検証 を素早く行える
- Spark ローカルモードや AWS Athena より 即時実行と反復開発 に向いている
- オートコンプリート機能付き UI を提供する
-
親しみやすいSQL構文
- DuckDB は ユーザーフレンドリーなSQL拡張 を多数含んでいる
EXCLUDE, COLUMNS, QUALIFY, ウィンドウ関数集計修飾子、関数チェイニング（first_name.lower().trim()）などをサポート
- これらの機能により、複雑なカラム選択・変換処理 を簡潔に行える
-
多様なファイル形式のサポート
- S3・Web URL・ローカルファイル などからデータを直接クエリできる
- CSV 型厳格性オプション を提供し、非構造的な入力データによるエラーを防げる
-
Python API
- Python で CTE ベースのパイプライン を段階的に定義し、各段階のデータを簡単に確認できる
duckdb.sql() 呼び出しで SQL をチェーン形式でつなげられる- 遅延実行（lazy execution） により、性能を損なわずに中間結果を確認できる
- 各段階ごとの関数テストが可能で、CI テスト効率が向上 する
-
ACID 準拠
- DuckDB は 大容量データ処理でも完全な ACID を保証 する
- この特性により、Iceberg・Delta Lake のようなレイクハウス形式に対する 中規模向け代替 として活用できる
-
高性能 UDF とコミュニティ拡張
- C++ で 高性能なユーザー定義関数（UDF） を作成できる
- Community Extensions により、
INSTALL h3 FROM community のようなコマンドで即座に拡張をインストールできる
- 例: 地理空間データ向け六角形インデクシング（h3） をサポート
-
ドキュメント
- 全ドキュメントを 単一の Markdown ファイル として提供しており、LLM 学習やコードエディタ内検索 に向いている
- コード折りたたみ機能により、必要な部分だけを簡単にコピーできる
実際の活用と効果
- オープンソースの Splink プロジェクトで DuckDB をデフォルトバックエンドとして採用した結果
- ユーザー課題の減少、作業速度の向上、機能開発・テストの単純化 を実現した
注目すべき拡張機能
- PostgreSQL Extension: DuckDB から Postgres データベースへ直接接続・クエリできる
- pg_duckdb: Postgres 内部に DuckDB エンジンを埋め込み、トランザクション処理と分析処理を並行 して行える
- 今後、Postgres インデックス最適化とフィルタープッシュアップの改善 が進めば、広範な採用の可能性 がある
2件のコメント
分散処理のためのParquetを単一マシンで処理する目的で使うというのは、皮肉ですね
Hacker Newsのコメント
私がDuckDBを気に入っている理由はいろいろある。
.parquet、.json、.csvファイルをすべてサポートしており、select * from 'tsa20*.csv'のように glob 読み込みができるので、数百個のファイルを1つのように扱える。スキーマが異なっていても
union_by_nameで簡単に結合でき、CSV パーサーが型をうまく自動推論してくれる。WebAssembly 版は 2MB、CLI は 16MB と非常に小さい。
そのおかげで製品に直接組み込める。たとえば Malloy のように。
Malloy は PowerBI や Tableau の技術者向け版のようなもので、セマンティックモデルを使って AI がよりよいクエリを書けるよう支援する。SQL を 10 倍簡単に書ける感覚だ。
以前はまずスキーマを理解するのに時間を使っていたが、今はデータを読み込んで探索クエリを書き、仮説を検証したうえで、整形・変換・テーブル作成の工程を繰り返している。
そのおかげで、はるかに速く深く掘り下げられるし、行き止まりも早く見つけられるので無駄が減った。
CSV パーサーの仕組みや今後の改善案を扱った論文があると聞いたが、まだ見つけられていない。
特に Parquet と JSON の ingestion が便利で、
clickhouse-localは DuckDB を組み込むという考え方に近い。SELECT ... FROM s3Cluster(...)構文で S3 バケットから ワイルドカード ingest ができ、クラスターノードに分散処理される。schema_inference_modeもサポートしているようだ。ClickHouse も
union_by_nameに似た機能を実装した。関連ドキュメント: s3Cluster 関数, schema inference, PR #55892
ただし Shaper は別言語ではなく SQL を使う。
DuckDB をベースに SQL だけでダッシュボードを作れる。
Shaper GitHub
速度は驚異的で、スキーマ自動検出もほとんど正確に動く。
LLM が自然言語クエリから正しい SQL を生成してくれる。
私は SQLite で手動 import するやり方だったが、DuckDB のおかげではるかに簡単になった。
私も DuckDB を愛用している。
BC の沿岸環境を研究する科学者たちと一緒に仕事をしていて、氷河観測から深海ドローンのデータまで膨大な量のデータを扱っている。
新しい生物多様性データ変換ツールのエンジンとして DuckDB を採用したが、目標は Darwin Core 標準に沿ってデータを変換・検証することだ。
DuckDB テーブルをスキーマベースで動的に生成してデータを import している。失敗した場合は行単位で理由を返す。
変換と検証もすべて DuckDB の中で行っている。
そのおかげで、はるかに高速で強力かつ ブラウザでも動かせるアプリケーションを作れた。
現場の研究者が iPad のブラウザでオフライン利用することもできる。
DuckDB によって SQL が重い処理を引き受けてくれるという安心感が生まれた。
型安全性が足りない部分はパースとテストで補っている。
このプロジェクトの目的は、科学者たちが 共通ツールで生物多様性・ゲノムデータを分析し、公開リポジトリに公開できるようにすることだ。
私は科学データ処理で HDF5 をよく扱うが、DuckDB は標準では HDF5 をサポートしていない。
既存の拡張は遅く機能も不足していたので、C++ テンプレートで新しい拡張を作った。
協力に関心のある人を探している。
個人的には Polars の文法のほうが SQL よりずっと楽なので、DuckDB を試す価値があるのか考えている。
私たちは Bluesky の分析とフィード処理を DuckDB で行っている。
結果をすばやく得るために Apache Arrow インターフェースを使い、SQG で DuckDB SQL クエリから直接コードを生成している。
Java プロジェクトの manifold-sql を紹介したい。
DuckDB SQL を 型安全にインラインで書ける。
SQL をコード内に直接埋め込み、
.fetch()で結果を走査できるので、中間レイヤーなしですっきりしている。筆者の主張は基本的なデータ処理には妥当だが、
「ほとんどの表形式データは単一マシンで処理できる」という部分には議論の余地がある。
データの拡張やピボット、増強をしていくとすぐに メモリ不足（OOM） が発生する。
また、「SQL は新しいデータエンジニアリングの第一選択であるべきだ」という主張も、複雑な分析にはあまり合わない。
Polars や pandas のような dataframe API にも多くの利点があるが、エコシステムが標準化されていないため、パイプラインを頻繁に書き直さなければならないのが問題だ。
ほとんどのデータは 10GB 以下なので、単一マシンでも十分処理できる。
Spark が過剰に使われている場合が多い。
私の立場は「まず DuckDB で試してみるべき」というものだ。単純なケースでは速くて効率的だ。
単純なパイプライン処理には SQL がよいが、可読性は人による。
私は dataframe のほうがずっと読みやすい。
ingestion 側は Python や Scala が多いが、SQL が消えることはないだろう。
OOM が問題になるのは極端なケースだけだと思う。
DuckDB が注目される一方で、Polars も過小評価されている。
私はデータ処理を多くするが、主に Polars を使っている。
とても高速で、pandas のように SQL では実装しにくい関数が多い。
Python 関数もそのまま使える。
DuckDB の性能が同じでも、SQL の 表現上の制約がありそうでためらってしまう。
スタンドアロンなのでインストールも簡単で、チューニングや学習コストがほとんどない。
メインフレームが生成した フォーマットがひどい Excel ファイルを DuckDB で読み込んだところ、
all_varcharオプションで 1 秒もかからずロードできた。Excel はまだファイルを開いている最中だ。
DuckDB は素晴らしいが、動的拡張の読み込みがコード署名と衝突するため商用アプリでは使いにくい。
また空間拡張は LGPL コンポーネントを使っていて、ライセンス面の問題がある。
Apache Arrow のように必要な機能だけを パッケージ単位で組み合わせられるとよい。
例: HTTP で GB/s 級の配列転送なら Arrow Flight、ファイル共有なら Arrow IPC、Parquet 読み取りは別 trait を追加。
DuckDB の SQL 型システムは Arrow と異なるため、型不一致の問題が起こりうる。
Arrow は大半の言語でネイティブライブラリを提供している。
数十億件の取引データ（30 列）を持つ単一テーブルで、
WHERE 条件で絞り込んだページを高速に取得できるのか気になる。
Postgres では単純な count(*) にも時間がかかる。
遅かったのは複雑な結合や多数ファイルの glob 処理くらいだった。
WHERE 条件が単純な列と値の組み合わせなら、かなり高速に処理できるはずだ。
DuckDB は単に速い DB というだけでなく、**開発者体験（devx）**が素晴らしい。
簡単に始められるのでエコシステムが急速に広がっている。
Web/WASM 統合も印象的だ。
こうした 小さなエンジンがもっと増えて、競争と革新が続いてほしい。