Toolmapソフトウェアの地図。制約つきで。
データの保存 種別：ツール 成熟度 安定 学習コスト 低

SQLite

サーバー不要、単一ファイルで動く組み込み型の関係データベース

分野「データの保存」：データをなくさず置いておく場所。形（表・文書・ファイル）で種類が分かれる。 この分野で最初に触るツールとして挙げている。 分野の役割とつながりは分野の解説へ。

別名：sqlite3、SQLite3、sqlite

できること

SQLite ができないこと

  • 複数のプロセスやホストからの同時書き込み（書き込みは常に同時1つ。待つか失敗する）
  • 複数サーバーからネットワーク越しに1つの DB ファイルを直接共有すること（ネットワークファイルシステム上のロックは信頼できず破損の原因になる）
  • ユーザー認証・権限管理（DB ファイルの OS 権限がすべて。テーブル単位の権限はない）
  • 日本語の全文検索を標準トークナイザだけで単語単位に行うこと（FTS5 の既定 unicode61 は空白区切り前提。trigram による部分一致で代替する）
  • 281 TB を超える単一データベース

制約

先頭の行が、このツールで最も先に当たる制約。値はすべて出典の一次情報で確認したもの。

項目 値 影響 出典 検証日
同時書き込み数 （主要制約） 1 ライター / 瞬間（読み取りは無制限）。WAL モードでも書き込みは同時に1つ 複数の Web サーバーやワーカーから同時に書き込むと SQLITE_BUSY で待ちや失敗が起きる。書き込み経路を1プロセスに集約するか、書き込みが分散する規模になったらクライアント／サーバー型 DB へ移す www.sqlite.org
WAL モードの動作条件 DB を使う全プロセスが同一ホスト1台上にあること。ネットワークファイルシステム上では動作しない 読み取りと書き込みを並行させる WAL は、NFS や SMB 越しに共有した DB では使えない。コンテナを複数ノードに広げた時点で前提が崩れる www.sqlite.org
1つの文字列 / BLOB の最大長 1,000,000,000 バイト（既定。SQLITE_MAX_LENGTH） 1 GB 近いバイナリを1行に入れる設計は成り立たない。大きなファイルは DB 外に置いてパスだけ保存する www.sqlite.org
データベースファイルの最大サイズ 約 281 TB（最大ページ数 2^32-2、ページサイズ 65,536 バイト時） 事実上の上限はファイルシステムと1台のディスク容量。ここに近づく前に用途が単一ファイル DB の範囲を超えている www.sqlite.org
1テーブルの列数上限 2,000 列（既定。SQLITE_MAX_COLUMN） 横に広い表（アンケートの全質問を列にする等）はコンパイル時設定を変えない限り入らない。縦持ちに設計を変える www.sqlite.org
1文中のホストパラメータ（? プレースホルダ）数 32,766（3.32.0 以降の既定。それ以前は 999） 「IN (?, ?, ...)」に数万件を渡す、1文で数千行をバルク INSERT する、といった書き方で「too many SQL variables」になる。分割するか一時テーブルに入れる www.sqlite.org

典型的な落とし穴

  • 型付けが緩く、既定では INTEGER 列に文字列を格納できる。STRICT テーブルを使うか、アプリ側で型を検証する前提で設計する
  • ALTER TABLE でできることが限られる（列の型変更や制約の追加はテーブルの作り直しが必要）。マイグレーションツールの前提を確認する
  • 既定はロールバックジャーナルで、書き込み中は読み取りもブロックされる。読み書きが混在するなら最初に WAL を有効にする
  • Dropbox や OneDrive などの同期フォルダ、ネットワークドライブに DB ファイルを置くと、ロックが機能せず DB が破損することがある

コスト

課金モデル
無料
跳ねる条件

パブリックドメインで、商用・非商用を問わず無償・無制限。費用が発生する要素はない

出典
www.sqlite.org 　検証

代替手段と差分

代替 何が違うか
PostgreSQL PostgreSQL はサーバーを1台立てる代わりに、複数プロセス・複数ホストからの同時書き込みと権限管理を持つ。SQLite は1プロセス・1ホストで完結するアプリやツールの組み込みに向く。アプリが複数台に増えた時点で PostgreSQL へ
DuckDB DuckDB も単一ファイル・組み込み型だが列指向で、大量行の集計に強い。SQLite は行単位の読み書きと小さなトランザクションに強い。アプリの状態保存なら SQLite、CSV や Parquet の分析なら DuckDB

このツールを代替として挙げているページ： DuckDB 、PostgreSQL 、Meilisearch

選定判断

1台で動くアプリ・CLI ツール・モバイル／デスクトップアプリのローカル保存、テストや試作の DB では第一候補。複数のサーバーやワーカーから同時に書き込む構成、ネットワーク越しに DB ファイルを共有する構成になった時点で避け、PostgreSQL へ移す

ライブラリとしてアプリに組み込む関係データベースで、DB は1つのファイル、サーバープロセスも設定も不要である。JSON 関数と FTS5 による全文検索を標準で持ち、小規模なら「文書の保存」「検索」もこれ1つで賄える。

利用者が最初に当たる制約は容量ではなく「書き込みは同時に1つ」という点である。読み取りは無制限に並行できるため読み取り中心の Web サイトでは問題にならないが、複数のワーカーが同時に書き込む設計にすると SQLITE_BUSY が頻発する。WAL モードで読み書きの競合は緩和できるが、書き込み同士の直列化は変わらない。