データ基盤

SQLiteとは|1往復が0.001msなら、1件ずつ引いても差は1.5倍しかなかった

何と比べる仕組みなのか往復がないと何が変わるのかどこから向かなくなるのか

一覧200件の関連を1件ずつ引くと、1往復0.8msの環境では80.6倍の差がつきます。

1往復が0.001msなら差は1.5倍です。同じ書き方でも、距離が変われば結論が変わります。

この記事の要点

  • 0.001msなら1.5倍
  • 0.01msで5.7倍
  • 0.8msでは80.6倍
  • 比べる相手はファイル操作

別のところで動く相手がいない

同じ処理の中で動くので、問い合わせは関数の呼び出しになります。往復がありません。

SQLiteの位置づけは、公式の1文にまとまっています。

SQLiteは、自己完結し、サーバーを持たず、設定を要さない、取引に対応したSQLのデータベース機構を実装した、処理の中で動く書庫であるという記述です。

「処理の中で動く」が要点です。問い合わせは、別のところにいる相手への依頼ではありません

比べる相手

公式は比較の相手も明示しています。SQLiteは、依頼と応答を分ける形のデータベースとは競合しない。SQLiteが競合するのはファイルを開く操作であるという言い方です。

書き込む先も同じです。SQLiteは通常のディスク上のファイルへ直接読み書きすると説明されています。

だから設定も要りません。置き場所を決めれば動きます

この違いが効く場面

往復がないと、問い合わせの回数に対する感度が下がります。次の節でその分を数えます。

逆に、1台に収まらない量や、複数の場所からの書き込みには向きません。同じ理由からです。

出典SQLite 公式サイト「About SQLite」2026-08-18 確認
SQLite is an in-process library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine.
原文SQLite 公式サイト「About SQLite」 この内容の有効期限2027-02-18

1往復が0.001msなら、1件ずつ引いても差は1.5倍しかなかった

往復の時間が短いほど、引き方の作法が効かなくなります。書き方の善し悪しではありません。

SQLiteでは、問い合わせが直接ファイルに届きます。公式も通常のディスク上のファイルへ直接読み書きすると述べています。

その分だけ1往復が短くなります。短くなると何が変わるかを数えました。

1往復の時間を変える

一覧200件の関連を引く場面です。返す行の数はどちらも同じで、引き方だけを変えます。

text
一覧200件で固定し、1往復にかかる時間のほうを変える

1往復      1件ずつ(時間)  まとめて(時間)  比
0.001ms              0.60ms            0.40ms    1.5倍
0.01ms               2.41ms            0.42ms    5.7倍
0.1ms               20.50ms            0.60ms   34.2倍
0.8ms              161.20ms            2.00ms   80.6倍
5ms               1005.40ms           10.40ms   96.7倍

1往復0.8msでは80.6倍です。別の場所にある相手に聞く場合の値になります。

0.001msなら1.5倍まで縮みます。同じ書き方が、環境によって問題にも問題でなくもなります。

縮まらない部分

0.60msと0.40msの差は0.20msです。201回の呼び出しにかかる分が残ります。

この分は消えません。往復がなくても、呼び出しの回数そのものは残るためです。

別の場所にある相手に聞く場合の比はMySQLの記事で数えていて、一覧1000件なら223.0倍でした。

距離が近づくほど、引き方の差が消えていく。

1件ずつ引いた場合の比(倍)1往復にかかる時間(ms)→1065.50.001ms0.01ms0.1ms0.8ms5ms一覧200件で固定した計算。左下に寄るほど、1件ずつ引く書き方の代償が小さい。
図1 ── 1往復の時間と、引き方による差
出典SQLite 公式サイト「About SQLite」2026-08-18 確認
SQLite reads and writes directly to ordinary disk files.
原文SQLite 公式サイト「About SQLite」 この内容の有効期限2027-02-18

網ごしに共有すると、利点が代償に変わる

公式も、その場合は別の方式を使うよう明記しています。ファイルとして扱う設計が前提です。

SQLiteには、公式が明示している向かない場面があります。

多くの依頼側のプログラムが、網ごしに同じデータベースへSQLを送るのであれば、SQLiteの代わりに依頼と応答を分ける形のデータベース機構を使うことという記述です。

理由も書かれています。網の上のファイル置き場でも動くが、多くの場合の遅延のせいで性能は良くならないという説明です。

何が起きるか

  1. 1往復が伸びる。前の節の0.001msが0.8ms側へ動く
  2. 取り合いの調整が遠のく。ファイル置き場の作法に依存する
  3. 書き込みが直列になる。同時に書ける相手が限られる
  4. 壊れたときの復旧が難しい。中断した書き込みが残る

1番目が直接効きます。近いことが利点だったのに、その前提が消えます

前の節の表でいえば、0.001msの行から0.8msの行へ移ることになります。1.5倍だった差が80.6倍になります。

向いている置き方

逆に言えば、データと処理が同じ場所にあるなら強い選択になります。設定も接続の管理も要りません。

1台に収まる量で、書き込む相手が1つなら、ファイルを1つ置くだけで済みます。公式がファイル操作と比べているのはこの意味です。

余談 この計測での注意

往復の時間は式で置いた値です。0.001msという値は同じ処理の中の呼び出しを想定したもので、実際には問い合わせの内容によって上下します。行を返す手間の0.002msも置いた値です。ここで見せているのは、引き方の善し悪しが環境の距離によって決まるという関係で、その距離は自分の環境で測れます。

出典SQLite 公式サイト「Appropriate Uses For SQLite」2026-08-18 確認
If there are many client programs sending SQL to the same database over a network, then use a client/server database engine instead of SQLite.
原文SQLite 公式サイト「Appropriate Uses For SQLite」 この内容の有効期限2027-02-18

よくある質問

SQLiteは何と比べる仕組みですか
公式は、client/serverのデータベースとは競合せず、ファイルを開く操作と競合すると述べています。
1件ずつ引いても平気ですか
往復が短ければ差は小さくなります。1往復0.001msなら1.5倍でした。
それでも差は残りますか
残ります。行を返す手間は同じですが、呼び出しの回数だけは減りません。
どこから向かなくなりますか
多くのプログラムが網ごしに同じデータへ書き込む場合です。公式もその場合は別の方式を勧めています。

まとめ

  • 同じ処理の中で動く
  • 往復がほぼない
  • 引き方の差も小さくなる
  • 網ごしの共有には向かない

今日から始められること

  1. 扱うデータが1台に収まるか確かめる
  2. 同時に書き込むプログラムの数を数える
  3. 網ごしに置く必要があるか確かめる
  4. 1往復にかかる時間を実際に測る

実務で組んだSQLiteのワークフローには、値段が付きます

同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。

出品の仕組みを見る