【図解で比較】SQLite vs DuckDB — 組み込みデータベースを用途で使い分ける

ひよこ

データベースってサーバーを立てないと使えないイメージがあるんだけど、サーバーなしで動くものもあるの？

ペンギン先生

あるよ！「組み込みデータベース」って呼ばれるタイプだね。アプリの中に直接データベースエンジンが組み込まれていて、別途サーバーを立てる必要がないんだ。その代表格がSQLiteとDuckDBだよ。

ひよこ

どっちも組み込みなのに、なんで2つも必要なの？同じようなものじゃないのかな？

ペンギン先生

実はデータの「得意な扱い方」がまったく違うんだ。SQLiteはOLTP、つまりトランザクション処理が得意。1件ずつデータを追加・更新・削除するような操作に強い。DuckDBはOLAP、つまり分析処理が得意。大量のデータをまとめて集計したり統計を取ったりするのに向いているんだよ。

ひよこ

OLTPとOLAPって、具体的にどう違うの？

ペンギン先生

たとえばECサイトで考えてみよう。「ユーザーが商品を1個カートに入れる」「注文を1件確定する」みたいな処理がOLTP。一方、「先月の全商品の売上をカテゴリ別に集計する」「過去1年間で売上が伸びた商品トップ100を出す」みたいな処理がOLAPだよ。扱うデータの「粒度」が全然違うんだね。

ひよこ

なるほど！でも、なんでそれぞれ得意分野が違うの？

ペンギン先生

データの格納方式が違うからなんだ。SQLiteは「行指向」で、1つのレコードのデータをまとめて保存する。だから特定の1行を読み書きするのが速い。DuckDBは「列指向」で、同じカラムのデータをまとめて保存する。「売上」など必要な列をまとめて読み、集計する処理に向いているんだ。実際の速度はインデックスやデータ、クエリによって変わるよ。

ひよこ

列指向ってそんなに速いの？どのくらい差が出るものなの？

ペンギン先生

データの量やクエリ、マシンによって差は大きく変わるから「何倍速い」とは言い切れないんだ。ただDuckDBは、まとまった値を一度にまとめて処理する「列指向・ベクトル化」という実行方式を採用していて、公式資料でもSQLiteなどの従来型より分析処理のオーバーヘッドが少ないと説明されているよ。しかもParquetやCSVファイルを直接SQLで読めるから、わざわざインポートしなくてもいいんだ。自分のデータで試して比べるのが確実だね。

ひよこ

ファイルを直接読めるのはすごく便利だね！じゃあ全部DuckDBにすればいいんじゃないの？

ペンギン先生

そうもいかないんだ。DuckDBの公式ドキュメントも、INSERTを1行ずつ大量に実行するのは非効率だと説明しているよ。通常の使い方では、同じデータベースファイルに複数のプロセスから同時に書き込むこともできない（別プロセスから書き込むためのリモートプロトコルは、2026年9月時点でベータ扱いだよ）。モバイルアプリやIoTデバイスのように「小さなデータを頻繁に読み書きする」場面では、SQLiteの方が向いているね。

ひよこ

つまり、用途によって使い分けるのがベストってことだね！実際にはどういう組み合わせがあるのかな？

ペンギン先生

両方を組み合わせる構成も選べるよ。たとえばアプリのデータ保存にはSQLiteを使いつつ、たまったログデータの分析にはDuckDBを使うパターン。DuckDBのsqlite拡張で既存のSQLiteファイルを参照できるから、コピーせずに試せる。ただしファイルの形式が自動でDuckDB形式になるわけではないよ。

ひよこ

組み込みDBだけでそこまでできるんだね。サーバー型のデータベースはもういらないのかな？

ペンギン先生

さすがにそれは言い過ぎかな。複数のサーバーから同時にアクセスする必要がある場合や、同時に書き込むユーザーが多い場合、複数のマシンで運用する必要がある場合はPostgreSQLやClickHouseのようなサーバー型も検討しよう。データ容量だけで組み込みDBが使えないとは決まらないんだ。SQLiteの公式資料も、こうした場面ではクライアント/サーバー型を勧めているよ。でも「1台のマシンで完結する」用途なら、SQLiteとDuckDBの組み合わせでかなりのことができるよ。まずは自分の用途がトランザクション寄りか分析寄りかを見極めて、適材適所で選ぶのが大事だね。

どちらを選ぶ？用途と同時書き込みで比較

同時アクセスの制約は「接続できる人数」とは違います。SQLiteに複数の接続があっても、書き込みは順番になります。DuckDBの説明は通常のプロセス内動作についてで、別途サーバー構成を採る場合の条件は区別してください。

DuckDBからSQLiteを読むと自動で列指向になる？

ATTACHしただけでは、SQLiteファイルがDuckDBの列指向形式に変換されるわけではありません。 sqlite拡張はクエリ時にSQLite側のテーブルを読みます。コピー不要で利用できる便利さと、DuckDBネイティブのテーブルと同じ性能が出るかは別です。

たとえば検証用のsample.dbにordersテーブルがある場合、DuckDB側で次のように参照できます。sqlite拡張を利用できる環境が前提です。

ATTACH 'sample.db' AS app (TYPE sqlite, READ_ONLY);
SELECT COUNT(*) AS order_count FROM app.orders;

この例は読み取り専用で接続しますが、拡張自体は書き込みも可能です。本番ファイルではなく検証用データで試し、SQLiteとDuckDBの型の扱いの差も確認してください。

Parquetを集計したい場合

amount列のあるorders.parquetをDuckDBで集計する例です。DBテーブルへ事前にインポートする必要はありません。

SELECT SUM(amount) AS total_amount
FROM read_parquet('orders.parquet');

ファイルの圧縮方式、必要な列、絞り込み条件で処理量が変わります。単に「SQLiteより何倍速い」とせず、同じデータと集計内容で確認しましょう。

補足

SQLiteでも小さなデータの集計はできますし、DuckDBもトランザクションを扱えます。この記事の分け方は設計の得意・不得意で、片方しか使えないという意味ではありません。速度は環境とデータで変わるため、数字はこの記事では示していません。

SQLiteの読み取りと書き込みは全部直列になる？

書き込みを同時に行えるのは1つですが、WALモードでは読み取りと書き込みを並行させられます。 「SQLiteは1人しか接続できない」という意味ではありません。ただしWALにもチェックポイントなどの運用があり、モードを変えれば同時書き込みまで増えるわけではありません。

SQLiteの行を頻繁に更新するアプリと、売上列をまとめて集計する分析では、読む範囲も処理の頻度も違います。図は同じ商品のデータを使い、この得意分野の違いを示しています。速さそのものを測った図ではありません。

選び方のまとめ

まずアプリの保存・更新が中心ならSQLite、CSVやParquetの分析が中心ならDuckDBを検討します。すでにSQLiteにデータがあるならsqlite拡張で試し、必要に応じて分析用のコピーを作る方法もあります。併用では型の扱いと書き込みの競合を確認してください。

参考資料

確認日：2026年10月4日。

• SQLite：Appropriate Uses For SQLite — 書き込みは同時に1つ、ネットワーク越し・大規模データではクライアント/サーバー型を検討。

• DuckDB：Why DuckDB — 分析（OLAP）向け、列指向・ベクトル化の実行エンジン、プロセス内で動作。

• DuckDB：Concurrency — 複数プロセスからの書き込みの制約、リモートプロトコルはベータ。

• DuckDB：Inserting Data — 1行ずつのINSERTを避ける推奨。

• DuckDB：SQLite Extension — ATTACHでSQLiteファイルを読み書き、型の違いと書き込みの制約。

• DuckDB — Reading and Writing Parquet Files：read_parquet、列・条件による読み取りの最適化。

• SQLite — Write-Ahead Logging：読み書きの並行性と同時書き込みの制約。

• DuckDB — ATTACH and DETACH：読み取り専用の接続とファイル形式の指定。