PostgreSQLで全部解決？— データベースの万能選手

私の一般的な経験則は、「Postgresが使えない理由がわかるまでPostgresを使う」というものです。

何かを導入するということは、運用・保守しなければならない可動部品が増えることを意味し、初期段階ではPostgresがおそらく処理できるでしょう。負荷を待って、どこで失敗するかを見てから、別のツールを追加する価値があるかどうかをよりよく判断できるようになります。

この種の投稿（「Postgres！全部これで十分！」）にはもううんざりです。PostgresはElasticの完全な代替には程遠く、それは最初の項目だけの話です。

リストを眺めていくと、「はい、極めて基本的なユースケースならPostgresで代用できます」と言うのは簡単ですが、これらの他のツールの機能を実際に必要とする場合、それはすべて通用しなくなります。

私はすべてにSQLiteを使っていて、それで完全に満足しています。同時書き込みの問題は認識していますが、私の規模ではそれは問題になりません。

> イベント、キュー、永続ログは、今日のソフトウェアシステムにおいてますます重要になっています。Kafka、RabbitMQ、SQSなどのシステムがその機能を提供します。しかし、それらを維持することは面倒で、カスタムが必要で、スキルセットも必要です。

技術スタックの選択では、可能な限りシンプルに保つことを好みます。とはいえ、概念を徹底的に理解している必要もあります。

上記の記事のコメントは、イベントアーキテクチャを簡素化する中央サーバーとしてPGを提案しています。まるで、それらの特定の代替手段に関する「面倒で、カスタムが必要で、スキルセットも必要な」部分が不要な荷物であるかのように。

キュー、スケーリング、可用性、アクセスセマンティクス、メッセージ形式、配信保証などの概念について何か知っているなら、キューに入ったメッセージを保存するサーバーがその方程式の最優先事項ではないことにすぐに気づくでしょう。

PostGISも、地理空間データの保存、インデックス作成、クエリに非常に便利な追加機能です。

http://www.postgis.net

記事のいくつかの点には同意しますが、いくつかのトピックは注意深く検討する価値があります。

* メッセージキューとして：

必要な機能が非常に基本的な場合のみです。たとえば、クラスター通信が必要で、その上で独自の調整プロトコルを実行する場合など。

* 高ボリュームの時系列データ：

Timescaleは機能しますが、同じDBサーバー上の他のワークロードとはうまく構成できません（スケール時の運用上の観点から）。

* ベクトルデータベース：

Timescaleと同じ問題があります。たとえば、PgVectorは独自の「世界」に存在し、クエリプランナーはそれを非常に不透明なものと見なします。既存の高ボリュームDBにベクターストレージを追加するのは忘れてください。他の複雑なクエリを処理する必要があるDBに追加するのは。PGVectorはキャッシュを破壊するか、CPUを占有して、以前は正常に機能していたワークロードが停止する可能性があります。これは私の意見ではpgvector自体の問題ではありません（彼らには敬意を表します）が、PostgreSQLの拡張APIがシステム全体にカスタムコストやトレードオフを公開するのがあまり得意ではないということです。

* 生データ：

小さなファイルには機能します...大量のデータを保存したい人がいるのはなぜか不思議ですが、それが輝くのは、内部キャッシュなどが生のファイルシステムアクセスよりもはるかに役立つ多数の小さなファイルにアクセスする場合です（ファイルシステムとそのチューニングにも多少依存します）。

* マイクロサービス：

サービスがデータベースモデルからJSONデータを公開するだけなら、そもそも存在すべきではないと思います。ビューを作成して終わりにしましょう。

この種の記事は、逆の方向に行き過ぎたために書かれる必要がありました。問題は、必要のない段階で、時期尚早にツールを使いすぎる人がいることです。だから、ええ、ほとんどの場合、Postgresだけを使う方がおそらく良いでしょう。私自身もその一人なので、自分がよくわかっているとは言いません。よりクールに感じるため、または「データベースで検索をする人はいないのでElasticsearchを使わなければならない」と感じるために、あまりにも多くのツールをセットアップするのは魅力的です。