2026年7月11日、Lobstersというサイトが、一見反直観的なことをした。彼らは十数年間稼働させていた有料のデータベースシステム（別サーバーを借りて走らせる必要があった商用ソフトのMariaDB）を、完全に無料のデータベース——SQLite——に置き換えたのだ。後者は「ファイル型」データベースと理解すれば良い。独立したサーバーも要らず、追加の請求も生まず、数行のコードで動く。
二日後の月曜の朝、サイトの保守者の一人がサイト内で投稿した。CPU使用率が下がった、メモリ使用量が下がった、ページの読み込みがより滑らかになった、と。最も肝心な一つはこうだ。「MariaDBのサーバーが完全に下架（廃止）されれば、月額のVPS費用がそのまま半減する。」
プログラマー仲間の間で、この投稿は炸裂した。384のいいね、92件のコメント。技術がいかにクールかではなく——むしろその逆で、あまりにも質素すぎることが理由だ。
七年越しのデータベース葛藤
今回の移行を語る前に、まずLobstersが何か簡単に説明しよう。それはプログラマー向けの「リンク共有＋議論」サイトで、より静かでよりハードコアなHacker Newsのようなものだ。ユーザーが技術記事を共有し、他の人が投票し、コメントする。サイトは大きくない——データベースファイルは約500MB、日々のトラフィックは普通の一台のサーバーで足りる——だが十数年間安定稼働してきた。
問題は使っていたデータベースにあった。昔、LobstersはMariaDB——独立したサーバーで稼働させる必要のある商用データベースシステム——を選択した。時間が経つにつれ、チームはこの構成が重すぎると感じるようになった。サーバーが一台増えるということは、月額請求が一つ増え、保守すべき故障の潜在的ポイントが一つ増えるということだ。2018年8月、主要な保守者のpushcxがGitHubで「PostgreSQLへの移行を議論する」というタイトルのディスカッションページを開いた——これまた有料のデータベースだ。
その議論ページは七年間寝かされ、方向はPostgreSQLからSQLiteへと漂った。本当の転換点は2025年初頭に現れた。投資グループのK1がMariaDBを買収し、コミュニティはMariaDBの長期的な将来性に疑念を抱いたのだ。同時に、Rahulというコミュニティメンバーがスレッドの中でこう尋ねた。「LobstersはSQLiteで動かせる？」
SQLiteとは何か。一言で言えば、すべてのデータをローカルファイルに保存する無料のデータベースだ。インストールも設定も不要、独立したサーバーも不要。それはChromeブラウザの中にも、WeChat（微信）の中にも、あなたのスマホのすべてのアプリの中にも組み込まれている——世界で最も多くインストールされているデータベースエンジンだ。だがある長い期間、それは「サイトには不向き」とデフォルトで見なされていた。なぜならその設計が、独立したサーバーを要する従来のデータベースシステム（MariaDB、PostgreSQL、MySQL）の考え方と異なっていたからだ。
Rahulのその一問が、このデフォルトの前提を覆した。
最初の移行：CPUが100%に張り付き、緊急ロールバック
2025年6月、thomas0というコミュニティのコントリビューターが正式に移行作業を引き受けた。彼は投稿の中で、珍しいほど率直な独白を記録している。プロセス全体で三回のコードコミットの試行、一度の失敗したリリース、その後三つの問題を修正してやっと成功した、と。
最初のリリースは2026年2月21日に起きた。thomas0とpushcxは電話で話し、詳細なデプロイリストを作り、すべては計画通りに進んだ——新しいコードが上がったその瞬間まで。サイトは読み取り専用モード（データが壊されるのを防ぐ保護措置）に入ったが、ユーザーの閲覧リクエストを処理するだけで、サーバーのすべてのCPUが100%に張り付いた。フリーズした。二人は半日ほど原因を探ったが、見つからなかった。結局のところ：ロールバックする、と決めた。
thomas0は投稿の中でこう書いている。「あの失敗の後、気分が良くなかった。」なぜなら彼は事前に、本番データベースへのアクセス権がないため、性能問題が隐患になり得ると知っていたからだ——だが彼の推測は証明された。
事後検証で、問題は三か所にあった。そのうち二か所は、SQLiteがデータベース内の最大の二つのテーブルに対して「全表スキャン」を行ったこと——まるで図書館で本を探す時に、第一列の本棚から一冊ずつめくっていき、目次で番号を引かないようなものだ。データ量が小さい時は問題ないが、データ量が大きくなると、誰かがページを開くたびにサーバーはテーブル全体を最初から最後まで読まねばならず、CPUは一気に満タンになる。三つ目は「N+1クエリ」と呼ばれる非効率なパターンだ。データを一つ検索するたびに、プログラムがさらにN個のクエリを発行してしまう。正しいやり方は、必要なデータを一度に全部取り出すことだ。
三か所の問題、二か所はSQLの書き方に、一か所はプログラムのロジックにあった。いずれもSQLite自体の欠陥ではない——二つの異なるデータベースシステムの間では、同じコードでもまったく異なる実行効率を生むのだ。
二度目の移行：静かな月曜の朝
2月21日のロールバック後、thomas0はわずか二日で三回目の修正をコミットした。彼は何をしたのか。
まず、最初のリリースで発見された二つの全表スキャン問題を修正した。クエリ文に適切なインデックスを追加した——言わば、その「大テーブル」たちに素早く探せる目次を作ったようなものだ。データベースに詳しい人にとっては基本中の基本だが、移行という文脈において肝心な点はこうだ。もともとMariaDB上では、これらのクエリは異なる実行経路を通っていたため、性能問題が露見することはなかった。SQLiteに替えると、同じクエリ文でもSQLiteは別の実行戦略——全表スキャン——を選んだのだ。データベースを替えたとたん、元の「良いコード」が「悪いコード」になった。
次に、N+1クエリを修正した。ループでのクエリをバッチクエリに変えた。プログラムはもう一つずつデータベースに尋ねるのではなく、必要なデータを一度にすべて引っ張り出す。
三つ目に、彼は一週間かけて、自分で書いたスクリプトでLobstersの実データ量の半分に相当するテストデータをローカルで生成した——本物の本番データを入手できないため、この方法でトラフィックをシミュレートするしかなかった。このスクリプト自体が一つの別の工数だった。
四つ目に、念のため、リリース前に「スロークエリログ」のスイッチを追加した。もしまだ発見されていない性能問題があれば、システムが自動的に実行時間が100ミリ秒を超えるクエリを記録し、迅速に特定できるようにするためだ。
2026年7月11日、二度目のリリース。今回の結末は違った。サイトは正常に稼働し続け、CPUとメモリの曲線は平稳だった。彼らはチャットチャンネルでユーザーのフィードバックを注視し、二つの小さな問題を処理し、それから月曜——トラフィックのピークという本当の試練——を待った。
月曜の朝、すべては平静だった。pushcxは内部チャットでこう一言述べた。「静かな月曜日だったな。」
なぜ「より単純な」データベースの方が良かったのか
この物語の反直観的な点はここにある。SQLiteはMariaDBよりずっと「簡素」だ——ユーザー権限システムがない、大量同時書き込みに対応しない、ネットワーク経由のリモートアクセスができない、高度なクエリ構文の多くにも対応しない。だがLobstersが乗せ替えた後は、すべてがかえって良くなった。
理由は三層ある。
一層目：サーバーが一台減り、面倒が一つ減る。 元の構成では、Lobstersのウェブプログラムは一台のサーバーで走り、MariaDBデータベースは別のサーバーで走っていた。二台のマシン間でネットワーク通信が必要で、それぞれを別々に保守し、別々にバックアップし、別々に監視しなければならなかった。SQLiteはデータベースをウェブプログラムの内部の一つのファイルに変えた——データは同じ一台のマシンにあり、バックアップはファイルを一つコピーするだけだ。Lobstersのように「一台のサーバーで全トラフィックを支えられる」サイトにとって、独立したデータベースサーバーは資産ではなく負債だ。
二層目：遅延の除去。 ユーザーがページを開くたび、ウェブプログラムはデータベースに問い合わせる必要がある。MariaDB構成では、この問い合わせは「プログラム→ネットワーク→データベースサーバー→ネットワーク→プログラム」と往復する。SQLiteに替えれば、問い合わせは「プログラム→ローカルファイル」になり、ネットワーク遅延という変数は完全に排除される。読みが多く書きが少ないサイト——たとえばリンク共有サイト——にとって、この変化がもたらす応答速度の向上は確かなものだ。
三層目：費用。 これが最も直観的だ。MariaDBのサーバーの毎月のレンタル代を、今は払わなくて済む。VPS費用がそのまま半減した。これは抽象的な「コスト削減・効率化」ではなく、請求書から一つの数字が消えたのだ。
thomas0は投稿でさらにいくつかの技術的ディテールを挙げている。SQLiteは符号なし大整数に対応しないため、あるIDフィールドの型を変える必要があった。SQLiteの照合順序はMariaDBより弱く、ASCII文字の大文字小文字無視のみに対応し、全UTF-8の表記処理には対応しない。SQLiteに欠けたいくつかの計算機能を補うため、ユーザー定義関数を使った、と。これらのディテールは一般読者にとって重要ではないが、一つの道理を示している。移行の本質とは、二つのシステムの間で、すべての機能が今まで通り働くような新しい経路を見つけることなのだ、と。
「足りれば良い」とソフトウェア業界の「複雑性崇拝」
この物語が、より多くの人に知られるべき真のの理由は、技術の層にはない。それはソフトウェア業界の根深い習慣に触れているからだ。「大きくて全部入り」の方案をデフォルトで選び、「足りる」方案ではなく。
Lobstersが当初MariaDBを選んだのは、当時のウェブサイト作成の標準的なやり方が「アプリケーション＋独立したデータベースサーバー」だったからだ。この構成は十数年前なら合理的だった——当時はサイトの成長期待が高く、トラフィックの変動が大きく、データベースにバッファ能力が必要だった。だが十数年が過ぎ、Lobstersの規模は質的な変化を起こしていない。今もなお中小のコミュニティサイトで、一日のトラフィックは普通の一台のサーバーで十分だ。しかしあの「いざという時のため」のデータベースサーバーは、毎月の固定出費をずっと生み出し続けていた。
これは孤例ではない。ソフトウェア業界には「早すぎる最適化」と呼ばれるよくある誤りがある。まだ来ない規模のために前払いで代償を払うのだ。スタートアップのたった三人のチームが、Kubernetesクラスタやマイクロサービスアーキテクチャ、マスター・スレーブのデータベースを組み上げる——「将来の拡張のため」だけに。これらの選択自体は間違っていないが、その代償は運用の複雑さ、月額請求、故障排查（トラブルシューティング）の難度の三重の上昇だ。
もう一層深く、筆者が指摘したいのはこうだ。技術の「先進」と「適切」は別の問題だ。無料でデータをファイルに保存する軽量データベースは、機能表の上では確かに商用データベースほど華やかではない。だが、あなたにその余分な機能——たとえばマルチユーザー権限、遠隔地レプリケーション、海量の同時書き込み——が不要なら、それらの機能は資産ではなく荷物だ。
もちろん、これがSQLiteがあらゆる場面に適しているという意味ではない。thomas0自身も、コメント欄でのネット仲間との議論の中で率直に認めている。もしサイトに大量の同時書き込みの需要があったり、複数のサーバーが同時に同じデータにアクセスする必要があったり、複雑なユーザー権限管理が必要だったりするなら、SQLiteは適した選択ではない、と。SQLiteの並行モデルは「マルチリード・シングルライト」——多人が同時に見るのは問題ないが、同時に書き込めるのは一人だけだ。Lobstersのような「ユーザーの閲覧が発言をはるかに上回る」コミュニティにとって、これは問題ではない。だが淘宝（タオバオ）やWeChat（微信）にとっては、これは災害になる。
肝心なのは、自分が本当に何を必要としているかを吟味するという動作の中に隠れている。この判断こそが、どのデータベースのバージョン番号を選ぶかより重要なのだ。
最後に
2018年8月にpushcxがあのディスカッションページを開いてから、2026年7月11日の二度目のリリース成功まで、Lobstersのデータベース移行はほぼ八年の歳月にまたがった。その間に一度の失敗、三回のコード修正、自作のテストスクリプト一つ、自作のデータベース移行ツール一つ、そしてチャットチャンネルでの「もう一度試してみるか」という無数の議論を経た。
最終結果は、一言で語り尽くせるほどシンプルだ。十数年稼働してきた老舗の技術コミュニティが、独立したサーバーを要する商用システムから、無料のファイル型データベースへデータベースを乗せ替えた。サーバー請求書は半減した。月曜の朝はとても静かだった。
これは「颠覆（ゲームチェンジ）」についての物語ではない。これは「足りることへの回帰」についての物語だ。
参考リンク
- Lobsters サイト内投稿：現在SQLite上で稼働中（thomas0 投稿）
- GitHub issue #539：MariaDBからPostgreSQL/SQLiteへの完全な歴史
- Simon Willison の報道：LobstersがSQLiteに移行
- pushcx のデプロイリストGist：二回のリリースの完全な操作手順
- Lobsters オープンソースコードリポジトリ（GitHub）