SQLite vs DuckDB：2026年のローカルデータベース選び

ここ数年データベース界を見ているなら、奇妙なパターンに気づいたはずです。2020年代で最も面白い2つのデータベースは、どちらも組み込み型です。インストールするサーバーも、動かすデーモンも、リモートホストへの接続文字列もありません。プロセスにリンクするライブラリであり、ディスク上のファイルを読み書きします。

SQLiteは言うまでもありません——20年にわたり組み込みデータベースのデフォルトであり、歴史上どのデータベースよりも多くのデバイスに載っています。しかし新顔はDuckDB。単一ファイル上で、インフラゼロのまま列指向・ベクトル化されたOLAPデータベースを動かせる、と人々が気づいた瞬間に爆発的に人気が出た組み込み分析エンジンです。

紛らわしいのは、外から見るとほとんど同じに見えることです。どちらも「SQLでクエリするファイル」。どちらもゼロインストール。データエンジニアもML関係者も個人開発者も使っています。それなのに、まったく違う仕事のために最適化されています——間違った方を選ぶと、データベースを使うのではなく戦うことになります。実際に役立つ判断基準を紹介しましょう。

一言で言うと

SQLiteはOLTPデータベースです。トランザクションのために作られています——大量の小さな読み書き、単一行の検索、単一マシン上に永続的でクエリ可能なストアを必要とするアプリ向け。

DuckDBはOLAPデータベースです。分析のために作られています——大きなスキャン、数百万行の集約、大きなテーブル間のジョイン、大量のデータから一度に答えを計算するクエリ向け。

これがすべての区別であり、他のほぼすべて——性能特性、ユースケース、失敗モード——はここから導かれます。

SQLiteが勝つところ

SQLiteは行指向ストアで、アプリケーションデータベースのワークロード向けに最適化されています。キーで行を探し、行を挿入し、行を更新し、コミットする。25年にわたってこのために調整されており、その効果は明らかです。

アプリにはこれが正解。 ローカルファーストのアプリケーション——デスクトップツール、モバイルアプリ、プラグイン、ゲーム、メモアプリ、データがユーザーのマシンに住むものすべて——を構築しているなら、SQLiteが答えです。並行読み取りと単一ライターのトランザクションをACID保証付きで処理し、あらゆるOSに組み込まれ、データベース界で最も実戦を積んだコードです。アプリの運用データ——アプリケーションロジックが絶えず読み書きする注文、ユーザー、設定、状態——はSQLiteに属します。

小型データベースの中では最高のエコシステム。 すべての言語に第一級のドライバがあります。すべてのプラットフォームにGUIツールがあります。iOS、Android、ブラウザ（IndexedDBのエンジン）、ほとんどのデスクトップフレームワークのデフォルトです。SQLiteを選ぶのは派手だからではなく、どこにでもあり**とにかく動くからです。

アプリの真実のソースに最適。 私にとってのキーユースケースはこれです。SQLiteはアプリケーションの現在の状態——コードが毎日読み書きする行——が住む場所です。アプリがその上で動いているデータベースであり、レポートを実行するデータベースではありません。

DuckDBが勝つところ

DuckDBは列指向・ベクトル化エンジンです。行を連続的に保存してスキャンする代わりに、列を保存し、現代のCPUベクトル化を活用し、ラップトップ上で毎秒数百万行を処理できます。この設計は、OLTPデータベースとしては最悪、分析エンジンとしては驚異的です。

分析にはこれが正解。 データ作業をしているなら——大きなCSVのクエリ、Parquetファイルの探索、ログの集約、1年分のイベントの指標計算、ローカルデータパイプラインの構築——DuckDBが答えです。ファイルをその場でクエリします。何もインポートせずにCSVやParquetファイルに対して直接SQLを実行できます。これは「大きなファイルがあって、答えが必要だ」という状況のデフォルトツールにした、たった一つの機能です。

モダンなデータスタックのために設計されている。 Parquet、Arrow、Polars、Pandas——DuckDBはそのすべてに収まります。ParquetをDuckDBのテーブルにロードすることも、直接クエリすることも、クエリ結果をParquetに書き戻すこともできます。データエンジニアにとって、これほど万能ナイフに近いものはありません。

ストレージとしてのSQLではなく、計算機としてのSQL。 メンタルモデルが違います。DuckDBでは通常計算しています——「この4000万イベントの平均セッション時間は？」——保存しているのではありません。だから列指向なのです。列指向ストレージは同じ列の多くの値を高速に読むのが得意で、集約がまさにそれを行います。

紛らわしい中間：SQLiteで小さな分析、DuckDBでアプリ？

ここでアドバイスが曖昧になります。正確に言います。

「分析もSQLiteでいいや——シンプルだから。」 できますし、データが小さければ問題なく動きます。しかし分析が数十万行に触れたり、いくつかのテーブルをジョインし始めると、行指向設計がコストになってきます。SQLiteで100万行のGROUP BYが遅いのは、SQLiteが悪いからではなく、列指向エンジンが列単位で読むものを行単位で読むからです。「ちょっとした分析」の習慣が本当のワークロードに育っているなら、DuckDBは同じSQLで桁違いに速いでしょう。

「DuckDBをアプリのデータベースにできる？」 技術的にはできます——トランザクションと書き込みに対応しています。実際にはやめましょう。DuckDBはバルク操作のために作られており、行単位の書き込みとポイントルックアップはまさに最も苦手な部分です。DuckDB上で頻繁な小さな読み書きを行うアプリは、SQLiteでは決して感じない鈍さを感じるでしょう。正しい道具を使いましょう。アプリの状態を保存するのはSQLite、分析するのはDuckDBです。

実際に機能するパターン：両方使う

見落とされているのはこれです。これらは競合ではなく、パイプラインです。2026年にうまく機能しているのを最もよく見る構成は次の通りです。

SQLiteがアプリの真実のソース。 現在の状態——注文、ユーザー、設定——はSQLiteに住み、アプリケーションがトランザクション的に書き込みます。
DuckDBがそれを分析。 DuckDBをSQLiteファイルに向けます——sqlite拡張経由でSQLiteデータベースを直接読めます——そして重い集約、ジョイン、前年比比較を実行します。数百万行をラップトップ速度で、インフラゼロ。

エクスポートのステップも、ETLも、2台目のサーバーもありません。分析エンジンがアプリのデータベースをその場で読みます。正直なところ、これは2つを一つにしたキラーケースです。

同じパターンは一般化します。DuckDBはParquetやCSVもその場で読むので、「自分が持っているものを、どこに住んでいようと全部クエリする」ための単一ツールになり、SQLiteは「アプリが必要とする状態を保存する」ための単一ツールのままです。

決め方：3つの質問

この質問を順番に自分に問うだけで、毎回正しい方にたどり着きます。

1. このデータはアプリケーションが一日中、行単位で読み書きするものですか？ はい→SQLite。それはOLTPワークロードであり、SQLiteの用途です。いいえ——分析対象のファイルだ——なら質問2へ。

2. クエリのほとんどは、多くの行に対する集約・スキャン・ジョインですか？ はい→DuckDB。それはOLAPワークロードであり、DuckDBの用途です。GROUP BY、ウィンドウ関数、大きな読み取り——DuckDBはこれらで行指向ストアを圧倒します。

3. データは小さく、クエリは単純ですか？ なら正直どちらでも動きます。アプリのデータベースになる可能性が少しでもあればSQLite、データが次々と届くファイル（CSV/Parquet）ならDuckDBを選びましょう。本当に小さな分析なら違いはノイズです。成長するものなら、違いは構造的です。

ローカルツールへの意味

これらのファイルを扱う方法には実際的な帰結があります。これはBasevoltというデスクトップデータベースツールを作る者として最も気にする部分です。ツールはエンジンと同じくらい重要です。.dbファイルを閲覧・編集・リレーション設定できるSQLite GUIは、パターンのアプリ側半分に不可欠です。DuckDBをファイルに向けるノートブックやCLIが分析側半分を担います。自分がどちらの半分にいるかを知れば、どのツール——そしてどのエンジン——を取るべきかがわかります。

アプリの状態を保存しているなら、分析ツールにストレージをさせようとするのをやめ、SQLiteに置き続けましょう。データを分析しているなら、行ストアに分析をさせようとするのをやめ、DuckDBにスキャンさせましょう。スタックの二つの半分は、それぞれが作られた仕事をした瞬間に、あなたに反抗するのをやめます。