私も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の利点が薄れてしまう感じ。

記事によると、UNLOGGEDテーブルはディスクではなくメモリに置かれるんだって。

アプリがあって、データがたくさんあって、実際の問題が出てくると、正しい選択肢を選ぶのがずっと簡単になるよ。PostgreSQLは、ほとんどのユースケースで中規模に達するには十分だよ。そこに到達すれば、ユースケースとテストデータがあるから、実際に必要なものを事前に予測するのではなく、代替案をしっかりテストできるようになる。アドバイスとしては、「PostgreSQLは今作っているものにはおそらく十分で、もっと大きくなってそれがうまくいかなくなるまで他の解決策を探すべきではない」という感じかな。

追加のスピードが必要だって証明してみて。自分のアプリケーションで、期待するベストケースの負荷のもとで、Redisをキャッシュに使うことでPostgreSQLよりも意味のある改善が得られるかどうかをベンチマークで示してみて。もし意味のある改善が得られないなら、PostgreSQLを使い続けた方がいいよ。

どっちでもないね。どうしても必要なら、クエリキャッシュにはmemcacheを使えばいいよ。でも、ほんとに必要な時だけね。無効化が難しいから。memcacheは安くて、信頼性も高く、成熟してて、速くて、スケーラブルで、理解するのも簡単。ほとんどの言語に decent なクライアントがあって、ステートフルじゃないし、ほとんどのクラウドプロバイダーでオフ・ザ・シェルフで使えるし、Kubernetesでも使えるよ。Redisの使い道を探してみたけど、PostgreSQLやPostgreSQL+memcacheの方がシンプルで優れた解決策だと思う。memcacheがどれだけ優れているかというと、数年で6つのノードで90億リクエストを処理して、プロセスの再起動なしで済んだことがあるよ。

アプリのキャッシュのニーズによるかな。もし中程度なら、PostgreSQLから始めるのがいいと思う。別のインフラや追加のコードを運用する必要がないからね。もし、アプリサーバーがリクエストごとに何も覚えてない「共有なし」アプローチ（RailsやDjango）を取っているなら、Redisは便利な選択肢になるよ。私はよく、長寿命のサーバープロセス（JVM）を使って、ライブキャッシングのニーズにも対応しているよ。#トレードオフ

それをやるべきだと思うよ、アーキテクチャがシンプルになるならね。例えば、FirestoreとRedisキャッシュレイヤーを使っているなら、それは2つのデータベースになる。もし2つのデータベースを1つ（PostgreSQL）に置き換えられるなら、それは価値があると思う。でも、Redisの代わりにFirestoreの前にPostgreSQLキャッシュレイヤーを使うことを提案しているなら、それはちょっとはっきりしないかな。

マテリアライズドビューはPostgresで結構うまく機能するよ。でも、ある程度の負荷がかかると、トラフィックを他で分散させるのが助かるんだよね。ただ、Postgresの外に出ると、トランザクション内での一貫した読み取りを保証できなくなる。通常はそれでも大丈夫だけど、絶対に必要になるまでPostgres内に留めておく理由としては十分だと思う。

RedisとPostgreSQLをキャッシュとして比較したいなら、記事で提案されているように、アンログテーブルを測定するのがいいよ。PostgreSQLの遅さの多くは、クラッシュ後の耐久性と一貫性を確保するためなんだ。それが問題でなければ、無効にしちゃってもいいよ。アンログテーブルはクラッシュ後に自動的にトランケートされるからね。

どれだけキャッシュする必要があるか、そしてどれだけのスピードが本当に必要かによるね。私はRedisが大好きだけど、最初の段階では、セットアップして別のアイテムを管理するためにかかる手間に対して、果たしてその価値があるのか分からない。幸い、検索はずっと考えられてきたテーマで、初めに切り分ける方法もたくさんあるんだ。ただ、過去の経験から、データベースの横にあるいろんな検索エンジンを見てきたせいで、スタックにもっと追加するよりも、最初はもっと簡単な方法があることが多いと思う。

私は「PostgreSQLをデフォルトの選択肢にしよう」という意味だと思ったよ。「何があってもPostgreSQLを使え」というわけじゃない。

「ただPostgresを使え」という一律のアドバイスには賛成できないな。これは、使えなくなる理由が出てくるまでPostgresを使うって意味だと思ってる。つまり、今のスケールや成長率に合わせて構築するべきで、「100万人のユーザーをどう扱うか」じゃない。シンプルな技術スタックの方が、反復作業が簡単だよ。

Citus Dataでは、Postgresの専門家がいるチームを持つ多くの顧客を見てきたけど、その主な仕事は常に調整や運用、要するにシステムを見守ってスケールを維持することだったんだ。ああ、必要なコア技術の専門家を雇う会社なんて！次は、彼らに良い給料を払うの？ちょっと待って、無関係な、すみません、「専門的な」SaaSツールをたくさん使う方が、確実に無関係な技術の専門家チームが5つも必要になるよりずっといいよね。Googleがその会社を買収したら、結局その技術は廃止されるんだから。まあ、真面目に言うと、「専門的」なのが良い時もあるけど、みんなが思ってるほど頻繁じゃないよね。専門家がいるのは悪くないし、むしろランダムな開発者にクラウド技術の専門家になれって言って、結局はまあまあな開発者を貧弱なDBAにしてしまうよりはマシだと思う。少人数のPostgres専門家が、驚くほど多くのPostgresを維持できることも忘れちゃいけないよ。

その通り。ユースケースは異なるからね。https://www.geeksforgeeks.org/mysql/difference-between-mysql...

私の経験では、「目的特化型システム」の機能はPostgresにあるけど、マニュアルを読まないといけないんだよね。個人的には、マニュアルを読んで調整するのは、リスクが比較的低いソフトウェア開発の形だと思ってる。

自分でもこれをやってみようと思ったことがある。MySQLの方がアップグレードも簡単そうだね。それにしても、Postgresに比べると停滞してる感じがする。

同じような状況だよ。Postgresの独特なところは本当にあるし、MySQLやSQLiteの方がずっと予測可能だね。

SQLiteは最高だよ。サービスを立ち上げたり、ポートを開けたりする必要もないし、必要な時に使えるちょっとしたデータベースがあるだけなんだ。

MySQLはDBのメンテナンスを考えたくないなら、確実に使いやすいよ。ただ、その分、スキーマがそれに合わせて設計されていれば、クエリのパフォーマンスを大幅に向上させることができる機能をたくさん諦めることになるけどね。例えば、BRINインデックスや部分インデックス、もっと良いパーティション管理など。逆に、MySQLのクラスタリングインデックスを活用するようにスキーマを設計すれば（1:Mの場合、子テーブルのPKを(FK, some_id)みたいにする）、範囲スキャンが信じられないほど速くなるよ。でも、実際にはそんなことをする人はほとんどいないけど。

ここにはPostgreSQLの理論と実践の間に興味深いギャップがあるね。このスレッドの他のところで、PostgreSQLの拡張機能がまだすべてをこなせないと不満を言ったけど、彼らができるべきことの一つは、代替ストレージエンジンを提供することなんだ。それが特に得意とされていることだから。じゃあ、VACUUMなしの、UNDOベースのMVCCストレージエンジンプロジェクトはどうして停滞したの？ https://wiki.postgresql.org/wiki/Zheap PostgreSQLにInnoDBがないのはどうして？（OrioleDBが同じ運命を避けられるかもね。）

私にとっての教訓は「Pineconeを使うな」じゃなくて、「Postgresを使い切った？」ってことかな。多くの場合、インフラが少なくてリスクも減るから、始めるときに時間を節約できるよ。もしPgの能力を超えるようになったら、そのときに代替を探せばいいんだ。