DuckDB を調べてみた（基礎と特徴編）

背景・目的

データ分析の現場では、これまで「手元のCSVやParquetをちょっと集計したいだけなのに、わざわざDWHにロードしたり、pandasでメモリに載せきれずに苦労する」という場面がよくありました。その選択肢の一つが DuckDB です。「SQLiteの分析版」とも呼ばれる、サーバー不要でプロセス内に組み込めるOLAP向けデータベースです。

普及も進んでおり、DuckDB公式ブログには次のようにあります。

DuckDB's Python packages has almost 25 million monthly downloads on PyPI alone.

DuckDB の Python パッケージだけで PyPI 上の月間ダウンロードが約2,500万に達しているとのことです（DuckDB v1.4 LTS 時点、2025年10月）。

この記事では、DuckDB とは何なのか・なぜ速いのか・どういう場面に向くのかという基礎と特徴を、公式ドキュメントをベースに整理します。

まとめ

先に結論として、DuckDB の全体像を表にまとめます。

項目	内容
これは何	サーバー不要でアプリのプロセス内で動く、分析（OLAP）特化の列指向SQLデータベース。「分析版のSQLite」と表現される
何ができる	①手元のCSV/Parquet/JSONを直接SQLで集計 ②pandas/PolarsのDataFrameをコピーせずSQLで操作 ③ノートPCから大容量データまで単一バイナリで分析
動作形態	別プロセスのサーバーを立てず、ホストプロセス（Python等）に組み込まれて動く（in-process / embedded）
なぜ速い	列指向 + ベクトル化実行エンジン。1行ずつでなく列単位のバッチ（ベクトル）で処理し、OLAPで高速
導入の軽さ	外部依存なし。C++コンパイラだけでビルドでき、単一バイナリ相当で配布される
ライセンス	MIT License（商用利用可。DuckDB Foundation が知財を保持し、恒久的にOSSを保証）

以降で、この各項目を公式ドキュメントに沿って掘り下げます。

概要

用語の整理

記事で繰り返し出てくる用語を先に整理します。

• OLAP（Online Analytical Processing）: 集計・結合など、データセットの大部分を読む分析寄りの処理。対義語はOLTP（1件単位の更新・参照が中心のトランザクション処理）
• in-process / embedded: DBが独立したサーバープロセスではなく、呼び出し側アプリのプロセス内で動く形態。SQLiteと同じ考え方
• 列指向（columnar）: データを行単位でなく列単位で格納・処理する方式。特定列の集計に強い
• ベクトル化実行（vectorized execution）: 1行ずつでなく、複数行をまとめたバッチ（ベクトル）単位で処理する実行方式
  • ここでの「ベクトル」は、ある列の値を固定個数まとめた処理バッチ（DuckDBでは data chunk と呼ぶ）のこと。ベクトルデータベースの「ベクトル」（MLが生成する埋め込み＝embedding）とは全く別の概念なので注意

DuckDB とは何か

DuckDB は、分析処理（OLAP）に特化した、プロセス組み込み型の列指向SQLデータベース管理システムです。オランダの研究機関 CWI（Centrum Wiskunde & Informatica）の Mark Raasveldt 氏と Hannes Mühleisen 氏によって開発され、2019年に最初にリリースされました。

位置づけとしては「SQLite の分析版」がわかりやすいです。SQLite は世界で最も広く使われているデータベースエンジンで、その普及ぶりはSQLite公式が具体的な数字で説明しています。

Since SQLite is used extensively in every smartphone, and there are more than 4.0 billion (4.0e9) smartphones in active use, each holding hundreds of SQLite database files, it is seems likely that there are over one trillion (1e12) SQLite databases in active use.

すべてのスマートフォン（アクティブ40億台以上）に組み込まれ、各端末が数百のSQLiteデータベースを保持するため、稼働中のSQLiteデータベースは推定1兆（1e12）を超えるとされています。この圧倒的な普及を支えているのが、インストールの簡単さとプロセス組み込み動作です。DuckDB はそのシンプルさとin-process動作の思想を受け継ぎつつ、SQLiteが不得意なOLAPワークロードに特化しています。

公式ドキュメントには次のようにあります。

DuckDB adopted the ideas of simplicity and in-process operation. For DuckDB, there is no DBMS server software to install, update and maintain. DuckDB does not run as a separate process, but completely embedded within a host process.

つまり、別途DBサーバーを立てて運用・保守する必要がなく、Pythonなどのホストプロセスに完全に組み込まれて動く、という点が土台になっています。

SQLite との違い（何が違うのか）

同じin-process系のSQLiteと比べると、狙う領域が異なります。SQLiteがトランザクション処理（OLTP）向けなのに対し、DuckDBは分析処理（OLAP）に特化しています。

観点	SQLite	DuckDB
主な用途	OLTP（1件単位の更新・参照）	OLAP（集計・結合などの分析）
データ格納	行指向	列指向
実行方式	1行ずつ処理	ベクトル化（列バッチ処理）
動作形態	in-process / embedded	in-process / embedded（同じ思想）

Wikipediaの記述でも、この対比が明確に示されています。

Unlike other embedded databases (for example, SQLite) DuckDB is not focusing on transactional (OLTP) applications and instead is specialized for online analytical processing (OLAP) workloads.

SQLiteのような他の組み込みDBと違い、DuckDBはトランザクション処理（OLTP）ではなく分析処理（OLAP）に特化している、という意味です。

この「OLAPに特化して高速」という特性を支えているのが、次に説明する列指向ストレージとベクトル化実行です。上の表で触れた「列指向」「ベクトル化」が、具体的にどう速さにつながるのかを見ていきます。

なぜ速いのか（列指向 + ベクトル化実行）

DuckDBの速さの核心は、列指向ストレージとベクトル化実行エンジンにあります。OLAPのクエリは、テーブル全体の集計や大きなテーブル同士の結合など、データセットの大部分を処理する重いものが中心です。この種のワークロードでは、1つの値あたりに費やすCPUサイクルをいかに減らすかが重要になります。

公式ドキュメントには次のようにあります。

DuckDB uses a columnar-vectorized query execution engine, where queries are still interpreted, but a large batch of values (a "vector") are processed in one operation. This greatly reduces overhead present in traditional systems such as PostgreSQL, MySQL or SQLite which process each row sequentially.

PostgreSQLやMySQL、SQLiteが1行ずつ順番に処理するのに対し、DuckDBは列単位の大きなバッチ（ベクトル）を一度に処理します。これによりOLAPクエリでのオーバーヘッドが大きく減り、行単位処理より高速になります。

この「ベクトル」は、ある列の値を固定個数（一般に1,024〜4,096個程度）まとめた処理単位を指す用語です。近年よく聞くベクトルデータベース（RAGなどで使う埋め込みベクトルの類似検索）の「ベクトル」とは無関係で、あくまでクエリ実行を速くするための処理バッチのことです。列の値をまとめて一括処理することで、CPUキャッシュやSIMDが効きやすくなり、1行ずつ処理するより速くなります。

紛らわしいのですが、DuckDBには埋め込みベクトルの類似検索を行う vss 拡張（Vector Similarity Search、HNSWインデックス対応）も別に存在します。こちらは本物の「ベクトル（embedding）検索」で、ここで説明している実行エンジンの「ベクトル化（vectorized execution）」とは全く別の機能です。同じ「ベクトル」でも指すものが違う点に注意してください。

なお、この実行エンジンは MonetDB/X100 の研究論文にインスパイアされたものです。公式ドキュメントの「Standing on the Shoulders of Giants」には次のようにあります。

Execution engine: The vectorized execution engine is inspired by the paper MonetDB/X100: Hyper-Pipelining Query Execution by Peter Boncz, Marcin Zukowski and Niels Nes. MonetDB/X100 later became the Vectorwise (Actian Vector) database system.

ベクトル化実行エンジンは、Peter Boncz・Marcin Zukowski・Niels Nes による論文「MonetDB/X100: Hyper-Pipelining Query Execution」に着想を得ており、この MonetDB/X100 が後の Vectorwise（Actian Vector）になった、という系譜です。

実行エンジン以外にも、DuckDB は複数の学術論文の知見を取り込んでいます。公式が挙げている主な論文は次のとおりです。

対象領域	論文
実行エンジン（ベクトル化）	MonetDB/X100: Hyper-Pipelining Query Execution（Boncz, Zukowski, Nes）
並列処理	Morsel-Driven Parallelism（Viktor Leis, Peter Boncz, Alfons Kemper, Thomas Neumann）
クエリ最適化	Dynamic Programming Strikes Back（Guido Moerkotte, Thomas Neumann） / Unnesting Arbitrary Queries（Thomas Neumann, Alfons Kemper）
並行性制御（MVCC）	Fast Serializable Multi-Version Concurrency Control for Main-Memory Database Systems（Neumann, Mühlbauer, Kemper）
セカンダリインデックス	The Adaptive Radix Tree: ARTful Indexing for Main-Memory Databases（Leis, Kemper, Neumann）

また、DuckDB自身の設計を記した査読付き論文として「DuckDB: An Embeddable Analytical Database」（SIGMOD 2019 demo）や「Data Management for Data Science - Towards Embedded Analytics」（CIDR 2020）が公開されています。

研究由来ながら、研究プロトタイプではなく安定した本番向けDBを目指して作られている点も特徴です。公式ドキュメントには「While DuckDB was originally created by a research group, it was never intended to be a research prototype. Instead, it was intended to become a stable and mature database system.」とあります。

導入が軽い（外部依存なし・ポータブル）

DuckDBは外部依存を一切持たず、コンパイル時にも実行時にも他のライブラリを必要としません。リリース時にはソースツリー全体がヘッダと実装の2ファイル（amalgamation）にまとめられ、C++コンパイラさえあればビルドできます。

依存がないおかげで移植性が非常に高く、Linux・macOS・Windows、x86・ARMの主要なOS/CPUで動きます。リソースの限られたエッジデバイスから、数テラバイトメモリ・100コア超の大規模サーバーまでスケールします。さらにDuckDB-Wasmを使えばWebブラウザやモバイル上でも動作します。

Thanks to having no dependencies, DuckDB is extremely portable. It can be deployed from small, resource-constrained edge devices to large multi-terabyte memory servers with 100+ CPU cores.

依存がないおかげでDuckDBは非常に移植性が高く、リソースの限られた小さなエッジデバイスから、100コア超・数テラバイトメモリの大規模サーバーまで展開できる、という意味です。

幅広い言語サポート

DuckDBはC/C++のネイティブAPIに加え、多くのプログラミング言語から利用できます。特にPythonとRに深く統合されており、対話的なデータ分析に向いています。

言語	補足
Python	Pandas・Apache Arrow・Polars のデータ分析パッケージに対応
R	Rに深く統合。対話的分析向け
Java	JNIで実装。Apache Arrow連携あり
Rust	ネイティブC APIをラップしたcrateとして配布
Go / Node.js / Julia / Swift	各言語向けAPIを提供
WebAssembly	DuckDB-Wasm（ブラウザ上で動作）

Pythonでの統合は特に強力で、DuckDBのPythonパッケージはpandasのデータに対してインポートやコピーをせずに直接クエリを実行できます。手元のDataFrameをそのままSQLで集計できるのは、分析作業では大きな利点です。

the DuckDB Python package can run queries directly on Pandas data without ever importing or copying any data.

DuckDBのPythonパッケージは、pandasのデータをインポートやコピーをせずに直接クエリできる、という意味です。

https://duckdb.org/why_duckdb
https://en.wikipedia.org/wiki/DuckDB

拡張機能とエコシステム

DuckDBは柔軟な拡張機構を持ち、新しいデータ型・関数・ファイル形式・SQL構文を追加できます。実際、Parquet対応・JSON対応・タイムゾーン・HTTP(S)/S3プロトコル対応といった主要機能の多くが拡張として実装されています。

コアチームが保守する主な拡張には次のものがあります。

• httpfs: HTTP/HTTPS/S3互換オブジェクトストレージへのリモートアクセス
• spatial: 地理空間関数（ST_*系）
• iceberg: Apache Iceberg テーブルの読み書き
• delta: Delta Lake テーブルの読み書き
• ducklake: メタデータをSQLデータベースに保持するレイクハウス形式（ACIDセマンティクス・タイムトラベル対応）

これらに加え、サードパーティによる30以上のコミュニティ拡張があります。

https://duckdb.org/docs/stable/core_extensions/overview
https://en.wikipedia.org/wiki/DuckDB

ライセンスと開発体制

DuckDBはMIT Licenseで公開されており、知的財産はDuckDB Foundationという独立した非営利団体が保持しています。開発は当初オランダの公務員（研究者）によって始まったという経緯があり、成果を広く社会に還元するという方針から、恒久的にOSSであり続けることが団体の定款で保証されています。

DuckDB is released under the very permissive MIT License and the project's intellectual property is held by the DuckDB Foundation.

DuckDB は非常に緩いMITライセンスで公開されており、プロジェクトの知的財産はDuckDB Foundationが保持している、という意味です。

なお、バージョン1.0.0は2024年6月3日（コードネーム SnowDuck）にリリースされ、後方互換のストレージ形式が保証される安定版となりました。以降も継続的にバージョンアップが続いています。

考察

現時点で調べた範囲での所感を整理します。

• 「サーバー不要でSQLの分析ができる」点が最大の魅力。DWHにロードする前の探索的分析や、手元のCSV/Parquetの集計に向いていそう
• 列指向 + ベクトル化実行という設計上、OLAP（集計・結合）で強い一方、1件単位の更新が多いOLTP用途はSQLiteなど他の選択肢が適する。用途の切り分けが重要
• Pythonでpandasのデータをコピーせず直接クエリできる点は、既存のデータ分析ワークフローに差し込みやすく、実務での導入ハードルが低そう
• 外部依存なし・単一バイナリ相当という導入の軽さは、CI環境やエッジ、ブラウザ（Wasm）まで幅広く効いてくる
• 次のステップ: 実際にインストールしてCSV/Parquetの直接クエリ、pandas連携、S3上のデータへのアクセス（httpfs拡張）を手を動かして検証し、実践編としてまとめたい

参考