SQLiteはapplication process内で動き、databaseを通常1つのfileとして扱う組み込みrelational databaseです。server processを別に管理しなくてもtransaction、index、SQL queryを利用でき、device、desktop application、local tool、test、小規模なapplication serverで有力な選択肢になります。
この記事の範囲
記事情報: 2026年1月12日初出。SQLiteと各serviceの公式資料を2026年7月25日に再確認しています。
この記事はSQLite本体の選定を中心にします。libSQLとTursoの接続方法・Embedded Replicasは、**TursoとlibSQLの導入ガイド**へ分離しました。
「SQLiteが分散databaseへ進化した」という表現は正確ではありません。SQLite本体、SQLite互換のfork、replication layer、managed serviceは別のproductです。
SQLiteが向く場面
SQLite公式は、client/server databaseと異なる問題を解くengineだと説明しています。dataとapplicationが同じdeviceにあり、運用を単純にしたい場合に特に適します。
- mobile・desktop・組み込みdeviceのlocal data
- application固有のfile format
- CLIやsingle-server applicationの永続化
- test・demo・学習用database
- temporary dataのsort・join・集計
- networkが不安定でもlocalで動く処理
CREATE TABLE notes (
id INTEGER PRIMARY KEY,
title TEXT NOT NULL,
body TEXT NOT NULL,
updated_at TEXT NOT NULL
);
CREATE INDEX notes_updated_at_idx
ON notes(updated_at);
設定が少ないことと、schema設計が不要なことは同じではありません。constraint、index、transaction、backup、migrationは必要です。
避けるべき構成
SQLiteは多数のreaderを扱えますが、同じdatabase fileへのwriterは一度に1つです。短いtransactionなら順番に処理できますが、多数のprocessが高頻度に書き込むsystemではclient/server databaseが適します。
network filesystem上のSQLite fileを複数machineから直接開く構成も避けます。latencyに加え、filesystem locking実装の問題が破損につながる可能性があるためです。
次の質問に該当する場合はPostgreSQLなども比較します。
- 複数serverが同時に大量writeするか
- databaseがapplicationとは別machineにあるか
- user・role・監査をDB serverで集中管理するか
- high availabilityとfailoverをDB engineに求めるか
- dataを1 fileへ置く運用が難しい規模か
WAL modeとtransaction
Write-Ahead Logging（WAL）はreaderとwriterの並行性を改善できますが、同時writerを複数にする機能ではありません。
PRAGMA journal_mode = WAL;
PRAGMA busy_timeout = 5000;
busy_timeoutはlockが解放されるまで待つ時間です。根本的に長いtransactionを解決するものではないため、外部API呼び出しや重い計算をtransaction内へ入れないようにします。
WAL fileとshared-memory fileを含むbackup・deployment方法も確認します。productionのsettingはdriverとhosting環境の公式guideを優先してください。
「分散SQLite」を分類する
SQLite周辺のserviceは同じ仕組みではありません。
TursoとlibSQL
libSQLはSQLiteをforkした先行projectです。現在のTursoは、remote接続用の@tursodatabase/serverless、local database用の@tursodatabase/database、localとcloudを同期する@tursodatabase/syncを用途別に提供します。@libsql/clientは既存コードやORMとの互換用途で利用できます。
LiteFS
LiteFSはSQLite databaseをreplicateする分散filesystemです。primary leaseやdeployment platformの構成を理解する必要があり、任意のSQLite applicationが自動的にmulti-writerになるわけではありません。
Cloudflare D1
D1はCloudflare Workersから利用するmanaged serverless SQL databaseで、SQLite semanticsを基盤にします。local SQLite fileを直接運用する形とは、API、transaction、deployment、制限が異なります。
これらを選ぶときは「SQLite互換」という共通点だけでなく、接続方式、write経路、consistency、region、backup、migration、障害時挙動を比較します。
選定表
| 要件 | 候補 |
|---|---|
| 1 device内で完結 | SQLite |
| 1 application serverとlocal disk | SQLite |
| remote APIでSQLite互換DBを利用 | Tursoのremote SDKやD1を個別評価 |
| localでread・writeしcloud同期 | Turso Syncなどの同期方式を評価 |
| 既存libSQLコード・ORMを維持 | @libsql/clientの対応状況を確認 |
| 複数writerを強く要求 | client/server RDBMSを評価 |
「edge」という名称だけで低latencyは保証されません。利用者、application、primary、replicaのregionと、read-after-write要件を図にして判断します。
運用で必要なこと
Migration
schema versionを管理し、application起動ごとに無条件で破壊的DDLを実行しません。旧versionから順に適用し、途中失敗をtestします。
PRAGMA user_version;
BEGIN;
ALTER TABLE notes ADD COLUMN archived INTEGER NOT NULL DEFAULT 0;
PRAGMA user_version = 2;
COMMIT;
Backup
database fileの単純copyは、write中やWAL利用時の整合性を考える必要があります。SQLite backup API、VACUUM INTO、hosting serviceのbackup機能など、公式に対応する方法を使います。backupはrestore testまで行って初めて有効です。
Constraint
SQLiteではforeign key enforcementを接続ごとに有効化するdriver構成があります。driver・ORMのdefaultを確認し、constraint violationのtestを入れます。
PRAGMA foreign_keys = ON;
判断手順
- dataとapplicationが同じmachineか確認する
- peak時のreader・writer数を見積もる
- transactionの長さとwrite頻度を測る
- offline、replication、region要件を分ける
- backup・restore・migrationを試す
- managed serviceなら停止・network分断時をtestする
SQLiteは「小規模専用」ではありませんが、single-file・single-writerという性質があります。その性質に要件が合うなら、複雑なserver運用を増やさず堅実に使えます。合わない部分を周辺serviceで補う場合は、SQLite本体とは別の運用責任が増えることを理解してください。
