DuckDBとは｜SQLite・pandasとの違いとDuckLake・MotherDuckの位置づけ

DuckDB

「ローカルのCSVやParquetを、まとまった行数のままSQLで集計したい」「pandasで読み込むにはファイルが大きすぎる」——分析用のスクリプトを書いていると、こうした場面によく出くわします。従来はこのためにサーバー型のデータベースを立てるか、pandasでメモリに載る範囲まで絞り込むかの二択でしたが、この隙間を埋める組み込み型のデータベースとして広がっているのがDuckDBです。

オープンソースのMITライセンスで、開発元はオランダの非営利団体DuckDB Foundationです（DuckDB Foundation公式サイト）。仕組みの詳細や具体的な使いどころは次章以降で、章立ては右の目次のとおりです。

01.結論：DuckDBを選ぶ基準

DuckDB・SQLite・pandas・クラウドDWH（BigQuery・Snowflakeなど）は競合というより、扱うデータの置き場所と規模で棲み分けています。比較に入る前に、自分たちが今どこで困っているかを確認しておくと選びやすくなります。

02.DuckDBとは何か

DuckDBは、オランダの研究者Mark Raasveldt氏とHannes Mühleisen氏が中心になって開発したオープンソースのデータベースです。現在は非営利団体Stichting DuckDB Foundationが知的財産の大部分を保有し、寄付によって開発を支える体制になっています。財団の理事にはRaasveldt氏・Mühleisen氏に加えてPeter Boncz氏が名を連ねています（DuckDB Foundation公式サイト）。

公式サイトはDuckDBを「SQLをサポートするリレーショナル（テーブル指向）DBMS」であり、サーバー不要のインプロセス（組み込み）データベースだと説明しています。SQLiteのシンプルさ・組み込み志向という設計思想を踏襲しつつ、大量データに対する複雑な集計クエリ（OLAP）に特化した点が最大の違いです（DuckDB公式サイト（Why DuckDB））。この立ち位置から、DuckDBはしばしば「分析用途のSQLite」と評されます。

開発の勢いは公開リポジトリの規模にも表れています。GitHubの公式リポジトリ（duckdb/duckdb）は、2026年7月時点で約3.9万スター・約3,400フォークを集めています。

開発は活発に続いており、DuckDB公式ブログによると2026年6月17日時点の最新版はDuckDB 1.5.4、長期サポート版はDuckDB 1.4.5 LTSです。両系統を並行してリリースし、LTS版は安定性を優先した枯れたバージョンとして維持されています（DuckDB公式ブログ（1.5.4／1.4.5 LTSリリースノート））。

03.DuckDBを支える仕組み

DuckDBの特徴の多くは、「分析クエリに最適化した実行エンジンを、サーバーなしで動かす」という設計判断から派生しています。ここでは、その設計が生む主要な仕組みを見ていきます。

列指向・ベクトル化実行エンジン

一般的なアプリ用データベース（SQLite・MySQLなど）は、1件のレコードをまるごと1行として保存する行指向ストレージを採用しています。1件を素早く読み書きするには向きますが、「全行のうち特定の3列だけを集計する」といった分析クエリでは、不要な列まで読み込むコストがかさみます。

DuckDBは列ごとにデータをまとめて保存する列指向ストレージを採用し、さらに1行ずつではなくまとまった単位（ベクトル）で処理を進めるベクトル化実行エンジンを組み合わせています。公式サイトによると、この構成により大量データに対するJOINや集計を伴う分析クエリを高速に処理できます（DuckDB公式サイト（Why DuckDB））。

サーバーを立てないインプロセス設計

DuckDBはPythonやアプリのプロセスの中に直接組み込まれ、別途サーバープロセスを起動する必要がありません。この点はSQLiteと同じ設計思想で、接続用の認証情報やネットワーク越しの通信を考えずに、ライブラリを読み込むだけで使い始められます。

一方でこの設計には代償もあります。複数のプロセスが同時に1つのファイルへ書き込むことは標準では想定されておらず、この制約と回避策は本番運用で確認しておきたい制約でまとめます。

ParquetやCSVを直接SQLで読み書きする

DuckDBはCSVやParquetのファイルを、いったんテーブルへ取り込まなくてもそのままSQLの対象にできます。公式ドキュメントによると、拡張子が.parquetのファイルならSELECT * FROM 'file.parquet'のようにファイルパスをテーブル名の位置へ直接書けます。拡張子が異なる場合や関数として明示したい場合はread_parquet()を使います（DuckDB公式ドキュメント（Parquet Files））。

-- ローカルのParquetファイルをテーブルのように扱う
SELECT card_id, count(*) AS rows
FROM 'snapshots/2026-07-07.parquet'
GROUP BY card_id
ORDER BY rows DESC
LIMIT 10;

-- HTTPS越しのファイルも同じ書き方で読める（httpfs拡張が必要）
SELECT * FROM read_parquet('https://example.com/sample.parquet');

同ドキュメントによれば、読み込み時には必要な列だけを読む「projection pushdown」と、条件に合わないファイル部分を読み飛ばす「filter pushdown」が自動的に働くため、事前の取り込み処理なしに大きなファイルへ直接クエリを投げても実用的な速度が出ます。

pandas・Polarsとの連携

DuckDBはPythonのローカル変数に入っているpandasのDataFrameを、そのままSQLのテーブルとして参照できます。DuckDB公式ドキュメントは、この仕組みを「replacement scan（置換スキャン）」と呼び、テーブル参照をDataFrameの読み取り関数へ透過的に置き換える処理だと説明しています（DuckDB公式ドキュメント（SQL on Pandas））。

import duckdb
import pandas as pd

my_df = pd.DataFrame({"price": [980, 1200, 850], "shop": ["A", "B", "A"]})

# my_df を取り込まず、そのままSQLの対象にする
result = duckdb.sql("""
    SELECT shop, avg(price) AS avg_price
    FROM my_df
    GROUP BY shop
""").df()

04.具体的な使いどころ：どんな分析に使われているか

DuckDBは汎用のSQLエンジンなので用途は幅広いですが、公式ガイドが扱う範囲から実際によく使われる場面を挙げると、次のようなパターンがあります（DuckDB公式ドキュメント（Guides））。

共通しているのは、いずれも「データを別のシステムへ移し替える前に、手元でSQLとして扱いたい」という場面です。次章以降では、この立ち位置を踏まえてSQLite・pandas・BigQueryとの違いを具体的に見ていきます。

05.SQLiteとの違い

「サーバー不要の組み込みデータベース」という点は共通していますが、SQLiteとDuckDBは想定する処理が正反対です。SQLite公式サイトは、SQLiteが行指向で「一度に1つの書き込みしか許さない」設計だと説明しています。読み取りは無制限に同時実行できますが、書き込みは順番待ちが発生します。多くのアプリではロックの持続時間が数十ミリ秒程度に収まるため実用上は問題になりにくいものの、多数のプロセスが同時に書き込みを続けるような用途にはクライアント・サーバー型のデータベースを勧めています（SQLite公式サイト（When To Use SQLite））。

「どちらが優れているか」という関係ではなく、行単位の読み書きが主役ならSQLite、列全体をまたぐ集計が主役ならDuckDBという役割分担です。同じアプリの中で、保存はSQLite・分析はDuckDBと使い分ける構成も珍しくありません。

06.pandas・Polarsとの使い分け

pandasやPolarsは「Pythonのメモリ上でDataFrameを操作するライブラリ」であり、DuckDBのような永続化されたデータベースとは役割が異なります。競合というより補完関係にあり、前述のSELECT ... FROM my_dfのようにDuckDBからpandasのDataFrameへ直接SQLを投げられるため、前処理・可視化はpandas、重い集計はDuckDBのSQLに任せるという分担がしやすくなっています。

この使い分けが特に効いてくるのが、ファイルサイズがマシンのメモリに収まりきらない場面です。pandasは基本的にファイル全体をメモリへ読み込んでから処理するため、数十GBのCSVやParquetを読もうとするとメモリ不足で落ちることがあります。DuckDBはディスク上のファイルに対してストリーミング的に処理を進められるため、先にDuckDBのSQLで絞り込み・集計してから、必要な結果だけをpandasのDataFrameへ渡すという順序にすると安定します。

07.BigQuery・Snowflakeとの違い

DuckDBは1台のマシン・1プロセスの中で完結するローカル実行のエンジンです。これに対しBigQueryやSnowflakeは、クラウド上に分散した計算資源を使い、複数ユーザーの同時アクセスや数十TB〜PB級のデータを前提に設計されたマネージド型のデータウェアハウス（DWH）です。データの置き場所と運用主体がそもそも異なるため、単純な優劣で比較できるものではありません。

DuckDBを土台にしたクラウドサービスであるMotherDuckは、自社比較として「Snowflake・BigQuery・Redshiftより高速かつ低コスト」とうたっています（MotherDuck公式サイト）。ただしこれは同社自身の比較であり、割り引いて読む必要があります。実務でよくあるのは「クラウドDWHから抽出したデータをDuckDBへ落として、ローカルで素早く前処理・試行錯誤する」といった、対立させずに併用するパターンです。

08.使い方：インストールから最初のクエリまで

Pythonから使う場合、サーバーのセットアップは不要で、ライブラリを1つ入れるだけで始められます。

import duckdb

con = duckdb.connect()  # インメモリ接続

con.sql("""
    SELECT card_id,
           median(price_jpy) AS price_median,
           count(DISTINCT shop_id) AS shop_count
    FROM 'snapshots/*.parquet'
    WHERE kind = 'buy'
    GROUP BY card_id
""").show()

SQLをコードから実行するだけでなく、テーブルをブラウザで眺めたい場合は、MotherDuckが開発・保守する公式UI拡張機能も使えます。duckdb -ui（またはSQLからCALL start_ui();）を実行すると、ローカルにWebベースのSQLエディタとテーブルビューアが起動します。既定ではクエリもデータもローカルから出ず、ノートブック風に複数クエリを整理して実行できます（DuckDB公式ドキュメント（UI Extension））。

09.本番運用で確認しておきたい制約

インプロセス設計であるがゆえの制約もあります。導入前に確認しておくと、後から構成を作り直す手戻りを避けられます。

仕様は今後のバージョンで変わりうるため、本番導入前に必ず最新のドキュメントを確認してください。

10.最新エコシステム：DuckLakeとMotherDuck

複数プロセスからの同時書き込みができないという制約に対して、周辺プロジェクトがそれぞれの角度から解決策を提供しています。2025年に登場したDuckLakeと、2022年設立・2024年に一般提供を始めたMotherDuckでは、周辺プロジェクトとして立ち上がった時期が異なります。

DuckLake：複数人で書き込めるレイクハウス形式

DuckLakeは、Parquetファイルによるデータ保存と、ACID（原子性・一貫性・独立性・永続性）対応のSQLデータベースによるメタデータ管理を組み合わせたレイクハウス形式です。公式サイトは「SQLで組み立てたレイクハウス形式」であり、DuckDB本体では未対応の複数インスタンスからの同時読み書き（「マルチプレイヤーDuckDB」）を実現する仕組みだと説明しています（DuckLake公式サイト）。

カタログ（メタデータ）の保存先にはPostgreSQL・SQLite・DuckDB自身などを選べ、スナップショットによる時点復元、スキーマ変更、統計情報を使った絞り込みに対応しています。DuckLakeは2026年4月にv1.0を公開し、後方互換性を保証する本番運用可能な段階に達したとアナウンスされました（DuckLake公式サイト）。DuckDB本体からは拡張機能として無料で利用でき、MITライセンスのオープンソースです。

MotherDuck：DuckDBを土台にしたクラウド版

MotherDuckは、DuckDBを土台にしたサーバーレスのクラウドデータウェアハウスです。公式サイトによると、最大の特徴は「hypertenancy」と呼ぶアーキテクチャで、ユーザー・顧客・AIエージェントごとに専用のDuckDBインスタンスを約100ミリ秒で起動し、使わない間は停止させることでリソースの奪い合いを避けています（MotherDuck公式サイト）。

S3・GCS・Azureのデータを取り込まずに直接クエリできるハイブリッド実行にも対応し、AIエージェント向けの機能として、対話的な可視化を作る「Dives」、エージェントが管理するデータパイプラインの「Flights」を提供しています（AIエージェントからDuckDB自体を操作する方法は次章で整理します）。無料プランと、月額基本料金からの有料プランがあり、具体的な料金はFAQでまとめます（MotherDuck公式サイト）。DuckDBで書いたクエリはそのままMotherDuckでも動くため、ローカルのDuckDBで検証してからMotherDuckへ持ち上げる、という移行のしやすさも特徴です。

11.AIエージェントとの連携のしやすさ

「Claude CodeやカスタムエージェントからDuckDBに直接クエリを投げたい」という需要に対しては、MotherDuckが公式のMCP（Model Context Protocol）サーバーを配布しています（motherduckdb/mcp-server-motherduck（GitHub））。接続先はローカルのDuckDBファイル・インメモリDB・S3上のデータベース・MotherDuckクラウドのいずれにも対応し、MCPクライアント（Claude Desktop・Claude Code・VS Code・Cursor・Gemini CLIなど）に対してexecute_query（SQL実行）・list_databases（データベース一覧）・list_tables（テーブル一覧）・switch_database_connection（接続先の切り替え）の4つのツールを公開します。

{
  "mcpServers": {
    "DuckDB": {
      "command": "uvx",
      "args": ["mcp-server-motherduck", "--db-path", ":memory:", "--read-write"]
    }
  }
}

ローカルで完結させず本番のエージェント基盤に組み込みたい場合は、MotherDuck側がフルマネージドで運用するリモートMCPも選べます（MotherDuck公式サイト）。MCPサーバーを使わずに独自のエージェントフレームワーク（LangChainなど）へ組み込みたい場合も、DuckDBはPython・Node.js・Java・Go・Rust・C/C++・ODBCなど多言語のクライアントライブラリを公式に提供しているため、SQL実行を1つの関数呼び出し（ツール）としてそのままラップできます。

12.どんな人に向いているか

前述の基準（結論）は困りごと別の選び方でしたが、ここでは携わる役割別に見てみます。

データの収集・整形・レポーティングといった定型作業を効率化したい場合は、次のTANTOUもご検討ください。

13.よくある質問（FAQ）

14.まとめ

ここまで見てきたように、DuckDBの強みはログ集計・ETLの前処理・時系列やGISの分析といった場面で、CSVやParquetを取り込まずそのままSQLとして扱える手軽さにあります。SQLiteとは行指向・列指向で得意分野が逆、pandasとは前処理と集計の役割分担、BigQuery・Snowflakeとはローカル実行かクラウド分散かという違いがあり、優劣ではなく対立させずに使い分けるのが実務的です。

一方で複数プロセスからの同時書き込みは想定されておらず、この制約を補う周辺プロジェクトとして、2026年に本番運用可能な段階へ達したDuckLake（複数人での書き込みを可能にするレイクハウス形式）と、以前からクラウドで稼働するMotherDuck（DuckDBを土台にしたクラウド版）があります。まずは無料で試せるDuckDB単体で自分の分析タスクに合うかを確かめ、共有やクラウド化が必要になった時点で周辺エコシステムへ広げる、という順序で検討すると選びやすくなります。