個人SaaSでSQLiteを選んだ理由 (PostgreSQLは過剰だった)
個人SaaSのDB選択はシンプル原則が優れた、SQLiteで困らないケースが多い
あなたが個人SaaSのDBに何を選ぶか悩んでいるなら、最初のリリースは SQLite で十分なケースが多いです。私のGramShift Desktop はリリースから1年以上経った今も SQLite で運用しており、ユーザー数が増えても問題なく動いています。この記事では SQLite を選んだ判断、PostgreSQL との比較、スケール限界の見極めポイントを共有します。
SQLite を選んだ3つの理由
個人開発SaaSのDBに SQLite を選んだ理由は、以下の3つに集約されます。
- 運用コストがゼロ: 別途DBサーバーを立てる必要がなく、ファイル1個で完結。バックアップは
cp gramshift.db /backup/で済む - 読み書き性能が想像以上に高い: 単一プロセスからの読み書きなら 10,000 QPS 以上をさばける
- VPS の構成がシンプル: アプリと DB が同一プロセス空間にあるため、ネットワーク越しのDB接続のレイテンシがゼロ
GramShift Desktop の場合、Web ダッシュボード (gramshift.com) で約30人の有料ユーザー、デスクトップアプリから1日数百回の API リクエストを SQLite で問題なくさばいています。書き込みも読み込みも全くボトルネックにならず、VPS の CPU 使用率は常に 10% 以下です。
PostgreSQL ではなく SQLite が向いている条件
個人SaaSで SQLite が PostgreSQL より向いている条件は、以下のパターンです。
- 単一サーバー (VPS 1台) でアプリが動く構成
- 同時接続数が数十-数百程度
- 書き込み頻度が秒間数十回まで
- 複雑なクエリ (JOIN 6個以上、ウィンドウ関数多用など) を多用しない
- レプリケーションやマルチマスター構成が不要
逆に、PostgreSQL が必要なケースは、複数サーバーで並行運用する構成、秒間数百回以上の書き込みがある、複雑な分析クエリを頻繁に走らせる、地理的に分散したマスター/レプリカ構成、などです。個人SaaSの初期-中期では、これらの要件はほぼ発生しません。
SQLite運用での注意点 — sql.js キャッシュ罠
GramShift で実際に踏み抜いた SQLite運用の罠を1つ共有します。Web ダッシュボードでは better-sqlite3 を使い、デスクトップアプリ内では sql.js (WebAssembly版) を使っていました。両者は同じ DBファイル を参照しますが、sql.js はメモリ内にデータを保持してキャッシュする仕様です。
あるとき、私がメンテのため VPS で sqlite3 コマンドで直接 DBファイルを更新したところ、デスクトップアプリ側で変更が見えない、という現象が発生しました。原因は sql.js のメモリキャッシュです。pm2 でWebサーバーを stop してから DB更新、再 start することで反映されます。直接 sqlite3 で DB更新する場合は pm2 stop が必須、というのが教訓です。
スケール限界の見極め基準
SQLite から PostgreSQL への移行を判断する基準は、以下のシグナルです。
- 同時書き込みエラー (SQLITE_BUSY) が頻発する
- VPS の I/O 待ち時間が CPU時間の 20% を超える
- ユーザー数が増えて、同時接続数が 500 を超える
- 複雑な分析クエリを daily に走らせたい要件が発生する
- マルチサーバー構成 (負荷分散、地理的冗長化) を採用したい
GramShift では、現状これらのシグナルは1つも発生していません。MRR が10倍以上になっても、おそらく SQLite で十分に持つと見ています。早すぎる最適化は個人開発の敵で、必要になってから移行すれば良い、というのが私の運用方針です。
「PostgreSQL から始めるべき」は思い込み
SaaS開発のブログ記事を読むと、「本番運用なら PostgreSQL 一択」のような書き方が多いです。これは大手SaaSや高負荷サービスの前提で書かれているため、個人開発SaaSにはオーバースペックです。「とりあえず PostgreSQL」を選ぶと、VPS構成が複雑になり、運用工数が増え、コードもDB接続周りで複雑化します。
個人開発の初期段階こそ、SQLite のシンプルさが活きます。後から PostgreSQL に移行する場合も、Prisma などの ORM を使っておけばコード変更は最小限です。技術選定はトレンドではなく、自分のスケール要件で判断するのが合理的です。