DuckDBはどのようにデータを動かさずSQL分析を実現したか

DuckDBの現在地は、サーバーを立てずに分析SQLを実行できるデータベースという一言に凝縮される。

CSVやParquetをその場で読み、PythonやRの分析環境にも入り込む。

巨大なデータ基盤を先に用意するのではなく、データの近くに分析エンジンを置く発想だ。出典

創業のきっかけ

DuckDBは、AmsterdamでDr. Mark RaasveldtとDr. Hannes Mühleisenによって作られた。

SQLiteが示した「簡単に配布でき、プロセスへ組み込める」価値を引き継ぎながら、対象をトランザクションではなく分析ワークロードへ移した。

外部依存を抑え、ホストプロセス内で動くことを最初から製品の中心に置いた。出典

Mark RaasveldtとHannes Mühleisenは、分析DBを別サーバーとして管理する前提を疑い、SQLをアプリケーションやnotebookのすぐ隣へ置いた。

これは機能を削った簡易DBではない。

複雑なquery、window function、ACID、columnar executionを一つの配布物にまとめる道だった。出典

転機と苦労

組み込み型DBは導入が軽い一方、データが大きくなるほどファイル形式、外部ストレージ、言語別client、extensionの整合性が問題になる。

DuckDBはCSV、JSON、Parquet、Icebergなどへの接続を拡張として積み上げ、PythonやRだけでなく複数言語のAPIを整備した。出典

2022年にはDuckLabsとMotherDuckのpartnershipが、local executionとcloud collaborationを分けて考える転機になった。

DuckDBそのものと、DuckDBを使うcloudサービスを同一視せず、異なる役割として接続する構図である。出典

成長と現在

2024年2月の0.10.0では、古いdatabase fileを新しいDuckDBで読めるbackwards compatibilityが強化された。

分析用途でノートブック、CI、アプリケーションに組み込まれるほど、性能だけでなく更新時の安心感が重要になる。出典

2026年8月、DuckLabsはAWSに加わると発表した。

Mark RaasveldtとHannes Mühleisenは、関連プロジェクトについて「The projects will remain open-source under the MIT license」と説明している。

商用組織への参加と、OSSのlicense・governanceをDuckDB Foundationに置くことを切り分けた点が、このプロジェクトの設計思想をよく表す。出典

結び

DuckDBの道のりは、分析をcloud warehouseの専用画面から解放し、データが存在する場所へ戻す試みだった。

組み込み、columnar、extension、OSSを別々の機能ではなく、導入摩擦を下げる一つの設計として束ねた。

今後の論点は、cloudとの接続が増えてもlocal-firstの速さと透明性を失わないことだ。

DuckDBのPMFは、データをwarehouseへ移送してから分析するまでの待ち時間と運用負債を減らしたいdata scientist、developer、embedded analytics担当にある。

CSVやParquetを直接SQLで扱え、Python/Rの既存workflowへ入るため、専用サーバーの導入なしに分析を始められる。出典

単なる軽量DBではなく、複雑なqueryとcolumnar executionを備えた分析専用の選択肢である点が、notebookからproductionのembedded analyticsまで用途を広げる。

最大のmoatは、vectorized analytical engineと、SQL・file format・language client・extensionを横断する実装知識の蓄積だ。

単一fileで配布できる単純さと、複雑な分析queryを処理する性能を同時に保つには、後発がAPIだけ真似しても届きにくい。

ネットワーク効果は中程度。

利用者が増えるほどextension、integration、GitHub issue、技術知見が増えるが、DBの実行自体は一人でも完結する。

強いsocial graphではなく、互換性とecosystemの蓄積型network effectである。

主な対象は、Python/Rで大量データを探索するdata scientist、warehouseへ送る前にローカルで変換したいanalytics engineer、アプリ内に分析機能を組み込みたいdeveloper。

高頻度のOLTPや厳格なmulti-tenant運用を単独で担うチームには第一候補ではない。

成功要因は三つある。

第一に、serverlessではなくin-processという導入単位を選び、依存関係とデータ転送を減らした。

第二に、CSV・JSON・Parquet・Icebergとextensionを通じて、既存データとの接点を増やした。出典

第三に、MIT licenseとDuckDB FoundationによるOSS governanceを明確にし、GitHub・docs・技術blogを成長チャネルにした。

この組み合わせが、academic researchとdeveloper adoptionを同じ方向へ向けている。

課題は、in-processの単純さがそのままmulti-userの共有基盤を意味しないことだ。

大規模な同時実行、権限管理、運用監視が必要な組織では、別のdatabaseやcloud serviceとの役割分担が要る。出典

また、extension・file format・各language clientが増えるほど互換性の維持は難しくなる。

DuckDB本体の売上やcommercial supportの規模は公開情報だけでは要確認であり、AWS参加後もOSS governanceとの境界を保てるかが不確実性になる。出典

成長はopen-source distributionを中心に進む。

Python/Rの分析者、CLI利用者、組み込み用途へ同じengineを配り、docsとclient APIで導入面を増やす。

MotherDuckのようなcloudサービスとの連携は、local-firstの採用を保ったままteam collaborationへ広げる経路になる。出典

一方で、commercial supportの収益化は本体のOSS性と緊張する。

AWS参加後もDuckDB Foundationがlicenseとgovernanceを担うと発表したことは、そのトレードオフを制度面で分離する試みと読める。出典

主要チャネル: open-source community, GitHub, documentation, technical blog, academic research

プロダクト設計では、既存カテゴリの機能競争に入る前に「どこで実行するか」を変える余地がある。

DuckDBはdatabase serverを高機能化する代わりに、分析処理をhost processとデータファイルの近くへ移した。

導入単位を変えると、性能・配布・developer experienceを同時に改善できる。

日本で展開するなら、製造・小売・物流の現場データを外部cloudへ集約する前のlocal analyticsに焦点を置ける。

ネットワーク制約やデータ持ち出し制限のある拠点で、ParquetやCSVをSQL分析できる形は実務に合う。

OSS本体とsupport契約、個人情報・越境移転の責任範囲を明確にすることが条件になる。