私もSQLiteのファンだよ。開発中の一番いいところは、コンテナなしでフルインテグレーションテスト用のデータベースを簡単に立ち上げたり、消したりできることだね。バックアップも簡単になるし、たぶん十分な性能だと思う。

「どのデータバックエンドを使うか」って話題は、みんなが何のためにそれを必要としているのかでいろんなバリエーションに混乱しちゃうよね。ここでの議論は本当にいろんな方向に行く。簡単なウェブアプリを作ってる人もいれば、数億人のユーザーにスケールする複雑なウェブアプリを作ってる人もいるし、ローカルアプリを作ってる人もいるし、ただいじってるだけの人もいる。バックエンドがデータレイクと組織のデータウェアハウスと同期する必要があることを広く考えてる人もいるしね。個人的には、他の人と共有する必要があるほぼすべてのユースケースにはPostgresが好きだよ（CRUDの更新を提供するかもしれない複数のクライアントがいるアプリとか）。SQLiteを2〜3人で共有する小さなアプリを作るためにWALを使ったこともあるけど、理想的ではなかった。Postgresは機能や拡張がたくさんあって、同時書き込みもめっちゃ速いし、一発で解決策を求めるなら間違いないけど、もちろんSQLiteの設定とは違うよね。Postgresの痛みの多くは、効果的に知識のあるDB管理者になることを学ぶことだと思う。開発者とDB管理者の専門家の間にいる感じだよ。実際に何かを本番環境でデプロイするなら、すべてが正しく設定されていることを願うのはちょっと怖いよね。Supabaseですら、このプロセスを簡単に始めるためには、あまり理解されていないセキュリティの前提を理解する必要があって、ちょっと不気味だし。正直言って、こういう議論からあまり得るものはないかな。みんなの仕事や趣味の生活には使い方や変数が多すぎて、どこに底があるのか分からない。SQLiteを使う人もいれば、Postgresを使う人もいるし、誰も聞いたことのない変なものを使う人もいる。生のSQLを使うのが怖いから、即座にGraphQL機能をデータ取得のメインモードにしたい人もいるしね。ここに来てRedisが必要な理由を話す人もいる。ノイズが多すぎるから、私はただPostgresを使い続けるよ。無料でつまらなくて速いからね。結局、使えるものを作りたいだけなんだ。これをうまくやるのは一人だと難しいし、他の専門家のチームがいて、正しい方法でデプロイするためのパズルのピースを組み合わせたり、Redisやその他のものを追加したりするのを手伝ってくれる人がいないと、本当に大変だよ。どこから始めればいいのかも分からないし。SQLiteは本質的に孤独な開発者を支援する唯一の解決策のようだけど、多くの人に使われるべきものを作ろうとすると、トレードオフが大きいよね。

多くの場合、時には（相対的な）シンプルさが欲しいこともあるし、複雑さやデプロイの面でもSQLiteみたいなものを使うべきだと思う。シンプルさを求めてSQLiteを使おうとすると、結局は面倒なことにぶつかって、解決するのが「セットアップして忘れる」Postgresのインスタンスを設定するよりも手間がかかることが多いんだよね。これは個人的なことだけど…「低メンテナンス用にパッケージ化されたPostgres」って、たくさんのOSパッケージマネージャーにあるよ！小規模なデータ分析でも、SQLiteのパフォーマンスにはまだまだ改善の余地があるし（以前、QGISがSQLite DBで苦労してたけど…pgはほぼ瞬時に処理してくれた。インデックスとかも…SQLiteでは簡単に得られないものもあったし）。もしSQLiteがうまくいくならそれは素晴らしいけど、シンプルなpgのセットアップを試してみる価値はあると思う。pgを使うのがどれだけ面倒かを理解するためにね（私にとっては、そこまで高くないけど）。

ウェブスケールじゃないから、mongoDBはウェブスケールなんだよね。

ちょっと話が逸れるけど、Postgresでユーザーアカウントに特定のデータベースへのフルアクセスを与える魔法の呪文が、簡単に信頼できる形で見つけられないんだよね。特にクラウドプロバイダーが提供するマネージドPostgresの場合。GRANT ALL PRIVILEGESは全然うまくいかないし。毎回権限を調べて修正するのが面倒で、シンプルな使い方でもPostgresを使うのが難しいんだよね。でも、アドホックで使うなら何かアドバイスある？

SQLiteを最も成功裏に使ったのは、実際には二つのユースケースなんだ。まず、データ処理に使ってる。大量のデータを取得して、別のセットアップに変換する必要があるとき、Pythonでもできるけど、SQLの方が表現力があって、新しいデータベースを作って、持ってるデータで埋めて、新しいデータを取得して組み合わせて、更新を永続的なデータストア（通常はPostgres）にエクスポートすることができる。二つ目は、ローカルのセーブファイルが必要なとき。小さなローカルアプリはセーブファイルの方が便利なこともあって、そのファイルは拡張可能なフォーマットにしておけば、後から更新できる。これはあまり一般的ではないけど、役立つこともある。最初のユースケースは非常に強力だよ。跡形もなく消せる一時的なSQLデータベースは素晴らしいし、複雑なクエリを実行できるのも本当に助かる。ただ、99%の時間はPostgresを使ってるけどね。ちゃんと動くし、デフォルトもまともだし、拡張性もすごいし、OracleやMySQLとは違って、今まで必要なことを満たしてくれたことがない。

一部の人は圧縮されたZFSボリュームでPostgresを使って大成功を収めているよ。

逆に、プレーンなPostgreSQLのダンプからの復元は、プレーンなMySQLのバックアップよりもずっと速いよ。MySQLには代替戦略もあるけど、それは余計な手間がかかるね。

問題は、Postgresが1行あたり約24Bのオーバーヘッドを使うことだね。小さいテーブルでは問題ないけど、数十億行になると、バイトがすぐに積み重なっていく。さらにリンクテーブルがその数を増やすから、データを大量に消費するんだよね。最終的には、スペースを節約するためにバイナリカラムやカスタムエンコードされた値を使うことになる。DBの利点が薄れてしまう感じ。