Just a File

PostgreSQLのバキュームにうんざりしていた。20代前半、駆け出しのエンジニアだった頃の話だ。

知人の広告代理店から、コンシューマ向け掲示板のリプレースを個人的に頼まれていた。ガラケーの時代だ。ニッチなジャンルの掲示板だったが、月間1000万PVくらいはあったと思う。PostgreSQLの運用が面倒だった。バキュームのチューニング、接続プールの管理、レプリケーションの設定。もっと軽いものはないのかと探していたときに、SQLiteを見つけた。

SQLが使える。ファイルひとつで完結する。インストールもデーモンも不要。開発環境で触ったとき、感動した。テーブルを作り、クエリを流し、JOINも効く。PostgreSQLでやっていたことがほぼそのまま動く。しかもバキュームも接続管理もいらない。これでいいじゃないか。

統合テストはすべて通った。いつものノリでリリースした。

ここまで書けば、まともなエンジニアなら結果は想像がつくだろう。

秒で落ちた。いや、気付くまで5分はかかったが。

行ロックという概念がSQLiteにはない。書き込みのたびにデータベースファイル全体がロックされる。一人で使う分には何の問題もない。だがユーザーが同時に書き込む掲示板で、ファイルロックが競合しないわけがなかった。書き込みが詰まり、タイムアウトが連鎖し、数分で使いものにならなくなった。

統合テストは一人のユーザーで流していた。並行書き込みのテストなんて書いていなかった。当たり前だ、開発環境では自分しか使わない。テストが通ることと、本番で動くことは別の話だ。

結局、うんざりしていたはずのPostgreSQLで作り直した。バキュームは面倒だが、少なくとも掲示板は沈まなかった。

それから20年近く経って、SQLiteの居場所はむしろ広がっている。DuckDBが注目を集め、SQLiteはブラウザに組み込まれ、クラウドのエッジコンピューティングでも使われるようになった。Tursoのような分散SQLiteまで出てきた。あの頃のわたしが聞いたら驚くだろう。

ただ、用途が変わっただけだ。

ブラウザのローカルストレージとして、エッジの一時キャッシュとして、組み込みアプリのデータ保存先として。どれも「単一プロセスからのアクセス」が前提の使い方だ。SQLiteの設計思想は変わっていない。

若いエンジニアがSQLiteを触って「SQLが使えるからデータベースだ」と言っているのを見ると、おいおいと思う。SQLが使えることと、RDBMSであることは違う。トランザクション分離レベル、行レベルロック、レプリケーション、接続管理。RDBMSはそれらすべてを背負っている。SQLiteは背負っていない。背負わないことで軽くなっている。

RDBMSと、SQLが使えるファイラー。その間には、あのときの掲示板を一瞬で沈めた程度の溝がある。