2024年、あえて言おう。データベースはPostgreSQLだけで十分だ

近年の複雑なテックスタックに疲れていませんか？多くのプロジェクトにおいて、PostgreSQLは単なるリレーショナルデータベース以上の役割を果たします。JSONBによるNoSQLライクな柔軟性、強力な全文検索機能、そして堅牢なACIDトランザクション。これら全てを備えたPostgreSQLがあれば、他の複雑なツールをわざわざ導入する必要はありません。シンプルに、そしてパワフルに。PostgreSQLこそが現代のベストな選択肢です。

PostgreSQLは、スケールする前に犯した設計の失敗に気づくまでは十分に使えるよ。結局、パーティショニングやHA、レプリケーション周りの判断を甘く見てると、どこかで限界が来るんだよね。

もっと踏み込んで言うと、大抵の場合は「SQLiteで十分」だと思ってる。とはいえ、大規模なものが必要なら自分はPostgreSQL一択かな。昔、ScyllaDB、Elastic Search、Redisなんかを詰め込んだ巨大なウェブアプリを移行したことがあるけど、結局PostgreSQL+PostGIS（マッピングアプリだからね）だけで済んじゃった。もちろん、それ以外の技術を検討すべき状況もあるだろうけど、ユーザーがつく前からそんなに複雑なものを構築するのは馬鹿げてるよ。

この記事がPostgresで置き換えられると主張しているものの多くは、Postgresが限界を超えた後にようやく検討するようなものばかりだよね。Kafka？誰もKafkaを運用なんてしたくないよ。もし真剣に検討するなら、それ専用の機能が必要な場合だけ。Elasticsearchも同じ。運用は最悪だし、検索のためだけに別のスタックを構築するなんて苦痛でしかない。Postgresが適さなくなった時に初めて検討すべきものだよ。Snowflakeだって同じこと。

ビジネスロジックをデータベース関数に詰め込むのは、破滅への最短ルートだ。

Postgresには利点があるけど、メッセージキューとしてはSQSを使うのが無難だね。去年、ほぼPostgresとdotnetサービス、そしてSQSキューで構成された取引プラットフォームを構築して、1億4000万ドルで買収されたよ。システムはシンプルに保てば、かなり強力なものを作れるってことさ。

Postgresは大好きだけど、アプリのロジックをデータベースに密結合させすぎるのは問題だと思う。ステートレスなコンテナ、Cloud Functions、VMを更新・ロールバックする方が、データベースを復旧させるより遥かに簡単だからね。

リンクされている最初の2つのリソース：

• シンプルに：コードをデータベース関数に移す
• 何でもPostgresでやる

これを見ただけで、これ以上読む価値はないって判断できる。リレーショナルデータベースは永続ストレージの一形態であり、重要な抽象概念やその関係性を永続的に管理するのには優れている。だけど、設計的にアプリケーションフレームワークやスケーラブルなメッセージングシステムではないんだよ。

リレーショナルDBMSとしてのPostgresは十分優秀だよ。ORMなんかで抽象化しようとする人たちに、その点はもっと主張しておきたいね。それに、jsonbのおかげでNoSQLはたいてい不要だし、PostGISのような特殊な型で他のユースケースもカバーできる。時系列データ向けの独自DSLを扱うより、SQLの方がずっとマシさ。もちろんインフラを増やしたくないなら、pubsub/キュー、pgvectorを使った検索、グラフDB、KVストア、キャッシュだってPostgresで済ませることはできる。

とはいえ、ここに挙げられている他の例はやりすぎな感じがするね。WebサーバーをPostgresでホストするなんて絶対イヤだし、データベース関数も控えめに使うべきだよ。

ビジネスロジックの大部分がデータベース関数やトリガーに入っている現場で働いたことがあるけど、正直言って追跡するのが本当に大変だった。そういったロジックの実装をすべてマイグレーションで管理する規律があればまだいいけれど、デバッグ時にそれらを繋ぎ合わせるのは相当な苦労だよ。多くの場合、そんな手がかりすら残っていない状態で、何が起きているのか頭を抱えることになるんだ。

以前の議論...

PostgreSQL is enough - https://news.ycombinator.com/item?id=39273954 (https://news.ycombinator.com/item?id=39273954) - 2024年2月 (316コメント)