DuckDB とは｜サーバー不要でParquet・CSVを直接SQL分析する使い方とSQLiteの違い

DuckDB とは、サーバーを立てずにアプリの中で動く分析用（OLAP）のSQLデータベースです。pip install duckdb の一行で入り、ParquetやCSVのファイルを取り込み作業なしでそのままSQLで問い合わせられます。「SQLiteの分析版」と説明されることが多く、実際に設計思想も近い位置にあります。

DevOps・自動化の道具立て全体は AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方 にまとめています。

DuckDBとはどんなデータベースか

DuckDBは、アプリケーション内で動作するインプロセス型の分析用（OLAP）SQLデータベースだ。SQLiteがトランザクション処理（OLTP）に特化しているのに対し、DuckDBは分析クエリに最適化されている。列指向のベクトル化実行エンジンにより、大量データの集計や結合を高速に処理する。

サーバープロセスが不要で、pip install duckdb だけで使い始められる。

主な機能とデータ分析での強み

• サーバーレス・組み込み型：外部プロセス不要。Python、Node.js、Java、Rustなどから直接利用可能
• ファイル直接クエリ：Parquet、CSV、JSON、ExcelファイルをインポートせずにそのままSQL分析
• 列指向ベクトル化実行：OLAP特化の実行エンジンで、集計・結合クエリが高速
• フルSQL対応：Window関数、CTE、サブクエリ、PIVOT、LATERALなど標準SQL機能を網羅
• pandas連携：DataFrameをゼロコピーでSQLクエリ対象にでき、結果もDataFrameで受け取れる
• 拡張機能：空間データ（spatial）、HTTP経由のリモートファイル読み込み、PostgreSQLスキャナーなど

インストールとデータ分析の始め方

# Python
pip install duckdb

# CLI（macOS）
brew install duckdb

# Node.js
npm install duckdb

Pythonでの基本的な使い方：

import duckdb

# CSVファイルを直接クエリ
result = duckdb.sql("SELECT * FROM 'sales_data.csv' WHERE amount > 1000")
print(result)

# Parquetファイルの集計
duckdb.sql("""
    SELECT category, SUM(amount) as total
    FROM 'transactions.parquet'
    GROUP BY category
    ORDER BY total DESC
""")

pandasとの連携：

import pandas as pd
import duckdb

df = pd.read_csv("users.csv")

# DataFrameに直接SQLを実行
result = duckdb.sql("SELECT age, COUNT(*) FROM df GROUP BY age ORDER BY age")
result.df()  # 結果をDataFrameに変換

CLIでの対話的クエリ：

duckdb

# S3上のParquetファイルを直接クエリ
SELECT * FROM read_parquet('s3://my-bucket/data/*.parquet') LIMIT 10;

なぜ「サーバーが要らない」ことがそこまで効くのか

分析用のデータベースというと、これまでは「専用のサーバーを立て、データを流し込み、権限を設計し、運用を続ける」ものでした。この初期コストがあるために、「ちょっと集計したいだけ」の用途では最初からデータベースが選択肢に入らず、pandasやスプレッドシートで済ませるという判断になりがちでした。

DuckDBはこの前提を崩します。プロセスもポートも設定ファイルも要らず、ライブラリとしてアプリの中で動きます。結果として、次のような場面で「データベースを使う」判断ができるようになります。

・一度きりの調査：手元に届いた数GBのCSVを、SQLで切り口を変えながら確認する。終わったら消す
・CI・バッチの中の集計：ジョブの一工程としてSQLを実行する。外部DBへの接続情報を持たせずに済む
・ノートブックでの分析：pandasのDataFrameに対して、読みづらくなりがちな多段のgroupby・mergeをSQLで書く
・アプリへの組み込み：デスクトップアプリやCLIの内部で、ユーザーのローカルデータを集計する

図のとおり、DuckDBは入力も出力も「今使っている形式」のまま扱えるのが特徴です。データを別の場所へ移してから分析する、という段取りが不要になります。

SQLite・PostgreSQLとの違い――どれを選ぶかの判断表

「DuckDB とは」を調べたとき、いちばん知りたいのは既に知っているDBとの違いのはずです。3つの軸で並べます。

DuckDBの使い方――ファイルを直接SQLで読む

DuckDBの最大の特徴は、テーブルを作ってINSERTする工程が要らないことです。ファイルパスをそのままFROM句に書けます。

-- CSVをそのまま集計する（インポート不要）
SELECT category, count(*) AS n, avg(price) AS avg_price
FROM 'data/sales.csv'
GROUP BY category
ORDER BY n DESC;

-- Parquetも同じ。ワイルドカードで複数ファイルをまとめて読む
SELECT date_trunc('month', ordered_at) AS m, sum(amount)
FROM 'data/orders/*.parquet'
GROUP BY 1 ORDER BY 1;

-- 別形式どうしを結合することもできる
SELECT o.id, u.name
FROM 'data/orders/*.parquet' o
JOIN 'data/users.csv' u ON o.user_id = u.id;

-- 結果をParquetで書き出す
COPY (SELECT * FROM 'data/sales.csv' WHERE price > 1000)
TO 'out/expensive.parquet' (FORMAT PARQUET);

Pythonからも同じSQLをそのまま使えます。

import duckdb

# ファイルを直接クエリして DataFrame で受け取る
df = duckdb.sql("SELECT * FROM 'data/orders/*.parquet' LIMIT 100").df()

# 逆に、手元の DataFrame を SQL の対象にできる（変数名をそのまま書く）
import pandas as pd
orders = pd.read_csv("data/sales.csv")
duckdb.sql("SELECT category, sum(price) FROM orders GROUP BY category").show()

# 永続化したいときだけファイルDBを開く（省略時はインメモリ）
con = duckdb.connect("analytics.duckdb")
con.sql("CREATE TABLE sales AS SELECT * FROM 'data/sales.csv'")

pandasと比べてどちらを使うか

Pythonでデータを扱っているなら、pandasとの使い分けが実務的な論点になります。どちらが優れているという話ではなく、書きやすさと規模で切り替えるのが現実的です。

実際には両方を行き来するのが普通です。DuckDBはDataFrameを直接SQLの対象にでき、結果もDataFrameで返せるため、「重い集計だけSQLに投げ、細かい整形はpandasで」という分担がそのまま書けます。移行のためにコードを全面的に書き換える必要はありません。

拡張機能で何が増えるか

DuckDBは本体を小さく保ち、機能を拡張としてロードする設計です。よく使われるものを挙げます。

・httpfs：S3やHTTP上のParquet/CSVを、ローカルファイルと同じ書き方でクエリできるようにする
・json：JSON/JSONL を構造のまま読み、ネストしたフィールドを展開する
・parquet：Parquetの読み書き（多くのビルドで最初から使える）
・postgres / sqlite：既存のPostgreSQLやSQLiteのテーブルを、DuckDB側からそのまま参照する

とくに httpfs と postgres 拡張の組み合わせは実務で効きます。「本番のPostgreSQLからマスタを引き、S3のログParquetと結合して集計する」という処理を、データを一箇所に集めることなく1本のSQLで書けるためです。拡張は INSTALL と LOAD の2行で有効になります。

INSTALL httpfs; LOAD httpfs;
SELECT count(*) FROM 's3://my-bucket/logs/2026-07/*.parquet';

2026年7月31日時点のバージョンと状態

v1.0以降は安定版として番号が進んでおり、1.5系のパッチが継続的に出ている状態です。組み込んで使う性質上、クライアントライブラリ（Python/Node/Java等）とDBファイルのバージョン整合は意識しておくと事故が減ります。古いバージョンで作ったファイルを新しいクライアントで開くときは、リリースノートで互換性の記載を確認してください。

競合データベースとの比較

差別化ポイント：DuckDBは「SQLiteの分析版」というポジションで、セットアップの手軽さと分析性能を両立している。ClickHouseは大規模分散処理に強いが、サーバー構築が必要。PolarsはDataFrame APIが中心で、SQLインターフェースではDuckDBが優位。

実務での使いどころ3パターン

1. 「届いたファイルを調べる」を毎回同じ手順にする

業務では、取引先やシステムからCSVやParquetがそのまま渡ってくる場面が多くあります。従来はExcelで開いて固まる、pandasで読み込んでメモリを使い切る、といった消耗が起きがちでした。DuckDBを間に挟むと、ファイルの形式が何であれ「まず件数と分布を見る」という手順を固定できます。列数が多くても必要な列だけを指定すれば読み込みは軽く済み、SUMMARIZE のような要約からデータの素性を掴めます。調査のたびに書き捨てるスクリプトが減り、SQLとして残せるのが実利です。

2. パイプラインの中間層として使う

ETL/ELTの文脈では、抽出したデータを一度どこかに置いてから変換します。この「置き場所」を専用のデータウェアハウスにすると、小規模なうちは費用と運用が重すぎます。DuckDBはファイル1つで完結するため、バッチジョブの中で一時的なウェアハウスとして立て、処理が終わったら結果だけをParquetで書き出して捨てるという使い方ができます。ジョブが失敗しても状態はファイルに閉じているので、再実行の副作用も読みやすくなります。

規模が大きくなり、複数チームが同時に参照する段階になったら、ClickHouse（クリックハウス）とは？仕組み・PostgreSQL比較・使いどころを2026年最新で解説 のようなサーバー型のOLAPへ移す判断になります。両者は競合というより規模と共有範囲による住み分けです。

3. アプリケーションに組み込んでローカル分析させる

デスクトップアプリやCLIツールの中で、ユーザーの手元にあるデータを集計したい場合、外部サーバーへ送るのは同意取得・通信・プライバシーの観点でハードルが高くなります。DuckDBはライブラリとして同梱できるため、データを外に出さずに集計処理だけを提供できます。手元のDBファイルを触るGUIが欲しい場合は dbx完全解説：20MBで70+DB対応のRust製DBクライアント｜MCP・CLI・Docker対応 のような軽量クライアントが使えます。