---

1ファイルで動くSQLiteがMySQLより速い理由

サーバー通信ゼロ！OSファイル開閉より35%速い

一般的なサーバー型データベース（MySQL や PostgreSQL）を使う場合、プログラムがデータを 1 件取り出すだけでも、「SQL 文をネットワークパケットに変換して送信 → データベースサーバー側で受信・解析 → 結果をまた通信で返却」という プロセス間・ネットワーク間の往復（いわゆる N+1 クエリで致命傷になる通信待ち時間） が毎回発生します。

これに対し、SQLite はサーバーではなく 「プログラム自身の部品（ライブラリ）」 として同じメモリ空間の中で直接動きます。通信の待ち時間が文字通り ゼロ（0 ミリ秒） であり、手元のメモリや SSD 上のデータを関数呼び出し 1 つで直接読み出せるため、何十回連続でクエリを投げても一瞬で終わります。

さらに SQLite 公式の有名な検証実験（『35% Faster Than The Filesystem』）では、数キロバイト〜数十キロバイトの細かいデータを「OS のフォルダに 1 個ずつのファイルとしてバラバラに保存して読み出す」よりも、「1 つの SQLite ファイルにまとめて読み出す方が約 35% 高速で、ディスク容量も約 20% 節約できる」 ことが実証されています。OS が何百回もファイルの「開く（open()）・閉じる（close()）」の権限確認を繰り返す手間を、SQLite がたった 1 回のファイルオープンで済ませてしまうからです。

読み書きを止めない『WALモード』とSSD相性

そして現代の SQLite を劇的に進化させた切り札が、次の 1 行で有効化できる 『WAL（Write-Ahead Logging：ログ先行書き込み）モード』 です。

PRAGMA journal_mode = WAL;

昔の SQLite はデータを書き換えるたびに本体ファイルをロックしていましたが、WAL モードを有効にすると、新しい変更分はまず横にある専用ファイル（-wal）のお尻へ 順番に追記（シーケンシャルライト） されていきます。これにより、「裏でデータを更新している最中でも、読み取り処理が一切待たされずに並行して爆速で動き続ける」 ようになり、現代の高速な NVMe SSD とも抜群の相性を発揮します。

---

万能ではない！SQLiteが苦手な2つの弱点

もちろん、SQLite は魔法の杖ではありません。採用する前に知っておくべき明確な弱点が 2 つあります。

比較項目	SQLite（組み込み・単一ファイル型）	MySQL / PostgreSQL（クライアント・サーバー型）
導入・管理の手間	設定ゼロ・1 ファイルをコピーするだけでバックアップ完了	サーバー構築、ユーザー権限管理、死活監視、定期パッチ当てが必要
読み取り・検索速度	通信往復ゼロのため小〜中規模では圧倒的に高速（数ミリ秒）	1 回のクエリごとに TCP / ソケット通信のオーバーヘッドが発生
大量の同時書き込み	苦手（書き込み自体は一度に 1 つずつ順番に処理される）	得意（行単位のロック等で何百・何千人の同時書き込みを捌ける）
複数サーバーからの共有	不向き（ネットワーク越しの共有フォルダ置きは破損の元）	得意（Web サーバーを何十台に増やしても中央 DB へ接続可能）

何千人も同時に書き込むシステムと複数台分散

SQLite が苦手なのは、X（旧 Twitter）や巨大 EC サイトの注文処理のように 「世界中の何千人ものユーザーが、同じ瞬間に一斉にデータを書き込み続けるシステム」 です。WAL モードでも「書き込みをする人」自体は一瞬ずつ順番待ちになるため、書き込みが殺到する巨大サービスや、複数台の Web サーバーから 1 つの DB を共有する構成では MySQL や PostgreSQL の出番になります。

個人開発やブログ管理では弱点が問題にならない

逆に言えば、「書き込むのは自分（またはバッチ処理）だけで、圧倒的多数はデータの検索・読み取り」 というスマホアプリ、デスクトップツール、個人〜中規模メディアの分析基盤においては、SQLite の弱点は 1 ミリも顔を出さず、「サーバー管理ゼロ・爆速・壊れない」というメリットだけを 100% 享受できるのです。

---

本番は静的のまま！500記事×AIのミリ秒検索術

全記事grepでAIのトークン枠が溶ける課題

Astro のような静的サイトジェネレーター（MDX 管理）は、記事が 50 本〜100 本のうちはテキストファイルのままでも快適です。しかし、当サイトのように公開記事が 約 500 本、さらに過去の AI 対話ログが 800 スレッド（数千万文字） を超えてくると、AI エージェント（Gemini 4 Argon や Claude）と一緒に記事を書くときに深刻な問題が起きます。

たとえば「この記事の数値を直したから、関連する他の記事も矛盾がないか探して」と頼むたびに、AI が 500 個の .mdx ファイルを毎回テキスト検索（grep）して何十ファイルも丸ごと読み込むと、時間ばかりかかる上に AI の週間トークン枠があっという間に溶けてしまう のです。

Node標準機能とmmapで0.03秒応答を実現

そこで当サイトが構築したのが、「テキスト原本（MDX）は一切変えず、Node.js v24 標準組み込みの node:sqlite（外部パッケージ追加ゼロ）でローカル知識 DB（knowledge.sqlite）を自動生成・差分同期する」 という 2 層分離アーキテクチャです。

---

日本語FTS5『2文字ヒットしない罠』と安全設定

最後に、これから Node.js（node:sqlite）で日本語の SQLite 全文検索を作る方がほぼ確実にハマる 「2 つの実務上の落とし穴」 と、その解決コードを共有しておきます。

trigramの3文字制限を補うハイブリッド検索

SQLite 標準の全文検索エンジン FTS5 で日本語を手軽に検索するには、文字を 3 文字ずつずらして索引を作る tokenize='trigram'（トライグラム） が非常に便利です。

しかしここには仕様上の罠があります。「3 文字ずつ切り出す」という構造上、『介護』『登山』『靴』『AI』『3%』のような「1〜2 文字の短いキーワード」を MATCH で検索すると、インデックスが機能せず検索結果が 0 件になってしまう のです！

これを防ぐには、検索語句の文字数を判定し、3 文字以上なら高速な FTS5 MATCH、1〜2 文字ならワイルドカードをエスケープした LIKE 検索へ自動で切り替えるハイブリッド関数 を組むのが正解です。

WAL併用時はimmutable禁止の鉄則コード

もう 1 つの罠が「読み取り専用で開くときの設定」です。ネット上の古い記事では URI パラメータの immutable=1（完全不変モード）を勧める例がありますが、裏で別プロセスが WAL 追記を行う環境で immutable=1 を使うと、最新の追記分が見えなかったりインデックス不整合エラー（SQLITE_CORRUPT 誤検知）を起こす危険 があります。

WAL 環境で安全に読み取り専用にするには、immutable=1 ではなく PRAGMA query_only = ON; を使いましょう。また node:sqlite はセキュリティと標準準拠のためダブルクォート文字列（"..."）を列名とみなす仕様（DQS=0）なので、SQL 内の文字列は必ずシングルクォート（'...'）で統一します。

import { DatabaseSync } from 'node:sqlite';

// 読み取り専用プロセスの安全な初期化例（Node.js v24+ 標準モジュール）
export function openReadDb(dbPath) {
  const db = new DatabaseSync(dbPath);
  // WAL環境では immutable=1 ではなく query_only = ON で誤書き込みを防ぐ
  db.exec(`
    PRAGMA query_only = ON;
    PRAGMA temp_store = MEMORY;
    PRAGMA cache_size = -32768;     -- 32MB ページキャッシュ
    PRAGMA mmap_size = 134217728;   -- 128MB OSメモリマップ
  `);
  return db;
}

// 日本語 1〜2 文字の取りこぼしをゼロにする FTS5 + LIKE ハイブリッド検索例
export function searchSections(db, rawKeyword) {
  const kw = String(rawKeyword ?? '').trim();
  if (!kw) return [];

  // サロゲートペアを考慮した文字数が 3 文字以上なら高速な FTS5 trigram MATCH
  if ([...kw].length >= 3) {
    const ftsPhrase = '"' + kw.replace(/"/g, '""') + '"';
    const stmt = db.prepare(`
      SELECT s.slug, s.heading
      FROM article_sections_fts f
      JOIN article_sections s ON s.id = f.rowid
      WHERE article_sections_fts MATCH ?
      ORDER BY bm25(article_sections_fts)
      LIMIT 20
    `);
    return stmt.all(ftsPhrase);
  }

  // 1〜2 文字語句（例: '登山', 'AI', '3%'）は LIKE 特殊文字をエスケープして確実に拾う
  const escaped = kw.replace(/[\\%_]/g, '\\$&');
  const stmt = db.prepare(`
    SELECT slug, heading
    FROM article_sections
    WHERE heading LIKE ? ESCAPE '\\' OR body_text LIKE ? ESCAPE '\\'
    LIMIT 20
  `);
  const pattern = `%${escaped}%`;
  return stmt.all(pattern, pattern);
}

このように「空文字のトリム」「1〜2 文字境界の分岐」「% や _ 記号のエスケープ」「WAL と競合しない query_only = ON」を押さえておくだけで、外部ライブラリに一切頼らない堅牢で超高速な検索基盤が手に入ります。

---

まとめ：適材適所でSQLiteは最強の武器になる

今回のポイントを整理します。

• SQLite が速いのは「通信往復ゼロ」だから : アプリと同じメモリ空間で直接動き、細かいファイルを OS で何度も開閉するより約 35% 速く、WAL モード によって読み書きの並行性も確保できます。
• 本番の静的サイト（Astro）とローカル SQLite は最高の相性 : 公開サーバーは DB レスの安全な静的 HTML のまま維持し、手元の制作環境にだけ SQLite インデックスを置くことで、セキュリティとミリ秒検索を両立できます。
• FTS5 trigram の 1〜2 文字対策と query_only = ON を忘れずに : 日本語の短い単語を取りこぼさないハイブリッド分岐を入れるだけで、数百記事・数千チャットの記憶を一瞬で引き出せる頼もしい知識庫になります。

「データベース＝重たいサーバー管理が必要」という固定観念を外してみると、たった 1 個の .sqlite ファイルが日々の執筆や AI 活用のスピードを劇的に変えてくれますよ！