インフラ・DevOps
Postgresがあるのに、本当に別のシステムが必要ですか?
Do you really need separate systems when you already have Postgres? (postgresisenough.dev)
要約
多くのチームがキャッシュ、キュー、検索、ドキュメント、ベクトル埋め込みのために別々のデータベースやシステムを導入していますが、Postgresだけでも十分な場合が多いと主張しています。複数のシステムは運用オーバーヘッド、メンテナンス負担、複雑さ、コストの増加を招きます。PostgresのJSONB、pgvector、TimescaleDBなどの機能を活用することで、これらのニーズの多くを満たせると提案しています。
全文翻訳
おそらく、別のデータベースは必要ありません。
キャッシュ、キュー、検索、ドキュメント、ベクトル埋め込みのために、Postgresがあるのに本当に別のシステムが必要ですか?
理由を読む
ツールを見る
要点
これはgistと活発なHacker Newsのスレッドから始まりました。前提はシンプルでした:Postgresはすべてにおいて最高ではありませんが、ほとんどの用途で十分です。実際には、ほとんどのチームはマイクロサービスやデータベースを多すぎます。すべてが時期尚早な最適化です。運用上のオーバーヘッドが増え、メンテナンスの負担が増え、監視の複雑さが増し、コストが高くなり、トレースが困難になり、デバッグセッションが長くなります。
典型的なパターン
キャッシュが必要なので、Redisを追加します。全文検索?Elasticsearchをボルトオンします。バックグラウンドジョブ?別のRedis、またはSidekiq。柔軟なスキーマを持つドキュメント?MongoDBをデフォルトにします。分析?Snowflake。イベント?Kafkaに手を伸ばします。
すぐに、あなたの「シンプルな」アプリケーションは、それぞれ独自のデプロイメント、バックアップ戦略、障害モード、そして互いに通信を停止したときの午前3時のアラームを持つ7つの異なるデータストアとマイクロサービスと通信するようになります。各システムは運用上のサーフェスエリアを追加します:監視、アラート、フェイルオーバーテスト、セキュリティパッチ、バージョンアップグレード。
「Webscale™」スタック
アプリケーション
Redis
Postgres
Elastic
MongoDB
Snowflake
Kafka
Pinecone
Sidekiq
InfluxDB
運用・監視する複数のシステム
アプリケーション
PostgreSQL
1つのデータベース。1つのバックアップ戦略。1セットの障害モード。
「しかしPostgresはWebscale™ではない!」
私たちはこの議論を常に耳にします。しかし、ソフトウェアプロジェクトのどのくらいの割合が実際にいわゆる「webscale」に達するのでしょうか?約0.3%?あなたのステルススタートアップやSaaSにとって、実際の課題ではなく、複数のマイクロサービスやデータベースにイノベーションのトークンを費やすべきでしょうか?Notion、Netflix、Instagramなどの何百万人ものユーザーにサービスを提供する企業が「退屈な」テクノロジーを信頼しているなら、あなたのスタートアップはおそらく7つのデータベースアーキテクチャなしでやっていけるでしょう。さらに、もしあなたが本当にwebscaleに到達し、Postgresの能力を使い果たしたら、必要になったときに、追加のコンポーネントを持ってくることができます。それが必要とされるとき、本当に必要とされるとき。
Postgresで十分かもしれない
別のデータベースに手を伸ばす前に、Postgresがすでに提供しているもので達成できるかどうかを確認してください:
あなたが必要とするもの... あなたが手を伸ばすもの... しかしPostgresには...
キャッシュ Redis, Memcached UNLOGGEDテーブル、マテリアライズドビュー →
ジョブキュー Redis + Sidekiq, RabbitMQ SKIP LOCKED, pgmq, pgflow →
全文検索 Elasticsearch, Algolia tsvector, pg_trgm, ParadeDB →
ドキュメントストア MongoDB, CouchDB JSONB, FerretDB →
ベクトル検索 / AI Pinecone, Weaviate pgvector, pgvectorscale →
時系列データ InfluxDB, TimescaleDB TimescaleDB, pg_partman →
分析 / OLAP Snowflake, BigQuery pg_analytics, DuckDB統合 →
グラフデータベース Neo4j, Neptune Apache AGE, 再帰CTE →
地理空間 Specialized GISシステム PostGIS →
本当に何か別のものが必要なとき
これはドグマについての話ではありません。時には、本当に専門的なインフラストラクチャが必要になります。しかし、その基準は高くあるべきです:Postgresを限界まで押し、なぜそれが不十分だったのかを文書化し、代替手段の運用コストを受け入れた後でのみです。それまでは、あなたが追加するすべてのシステムは、その利点が長年のメンテナンス、監視、デバッグのコストを上回るという賭けです。
この哲学を形作ったエッセイを読む