kmakanae

この疑問から2ヶ月後の今、自分で答えを見つけた。 サーバーアプリでもSQLiteを採用するのが正しい場面は、「ちょっとした業務アプリの開発」だ。 スタートアップで本格的なシングルプロダクトを作るなら、無難にPostgresを採用する。 しかし、これには見えにくいダウンサイドがある。 まず、Postgresをローカルの開発環境にセットアップすることを考える。 このとき、1個のPostgresをHomebrewなどでインストールしてプロジェクトごとに異なるDBを作ってもいいが、これだとPostgresのv15, v16などを共存できなくなり、バージョンに依存した問題の再現や機能の利用ができなくなる。結果、あまりプロジェクトを増やしたくなくなる。 これを解決するには、Dockerを使う。プロジェクトごとにコンテナを分けてしまえば環境をクリーンに分離できる。軽量でサクサク動くOrbStackなどのGUIも出てきた。 ところがこの場合、プロジェクトが増えてくると同時起動しているDBインスタンスが増えてきて、メモリを圧迫する。また、OS再起動時などに落ちてることがあって意外と認知コストを消費する。結果、あまりプロジェクトを増やしたくなくなる。 こうした問題は、SQLiteでは起きない。SQLiteは、ただの local.db ファイル。これをプロジェクトのフォルダー配下に置いて gitignore しておくだけで、いつでもプロジェクトを起動すればアクセスできる状態になるし、終了すればメモリから消える。 プロジェクトが100個になっても、DBがメモリを食ってるという意識で気持ちがザワつくことはない。あくまでプロジェクトでnpm run dev / rails sしているあいだだけの関係。 そして、自分も遅まきながらSQLiteの近況を少し調べてみたのだが、今はSQLiteのコミュニティーフォークのLibSQLが設計のモダナイズに貢献していて、WebSocketsなどによるリモート接続のみならず、レプリケーションやPITRなども実現している。production-readyと言っていいだろう。 そして、Tursoなどのサービスが出てきている。Tursoは、無料版でも500個のDBを作成できる。500個！ turso.tech 月9ドル払えば、コールドスタート問題もなくせる。35箇所のリージョンで、500個という、ほぼ無制限のプロジェクト数に対して。これぐらいなら個人でも気持ちよく払える。 これは本当に大きな変革かもしれない。 今の世の流れは、AIの後押しもあって、少数精鋭のエンジニアが何でもサクッと作ってしまう時代だ。できるエンジニアが担当するプロジェクトの数は増える。 たくさんのプロジェクトを抱えた高級エンジニアのDX（開発者体験）を改善する方向に世の中は動く。 そして何より、DockerもHomebrewもいらない、となれば、Voltaでnode / pnpm入れてVSCodeをダウンロードするだけで、非開発者であっても開発環境を簡単にセットアップできることになる。 ソフトウェアのインハウス化、ペインを抱えた現場がオーナーシップを持つコードベース、という世界観に一歩近づいたと言えるだろう。ちょっとした自動化のタスクなどを、現場の人たちが気軽にWebアプリとしてデプロイしてしまう世界観。 そして中途半端なスキルのエンジニアの需要は減り、ドメイン知識をもった現場の人が直接メンテする。そういう現場にスキルをトランスファーできるレベルの高級人材に需要が集中する。 その世界に向かうために欠けていたパズルのピースが、DBだった。プロダクションで使えるSQLiteは、そのギャップを埋めてくれる。 という気付きがあった。 これからは軽量アプリは基本SQLite + Turso、本格的なアプリだけPostgres or MySQLという区分けでセットアップしてみようと思う。