Postgres vs. NoSQL — 2026年の技術選択とその限界
「デフォルトで Postgres を選び、必要になったら NoSQL を追加する」というアドバイスは、ここ数年、複数の技術リーダーによって繰り返し提唱されてきた。DHH による Rails 界隈での主張、37signals の ONCE / Once Retention の技術構成、Simon Willison の SQLite 推しなど、関係型データベースへの回帰的な言説が目立つ。しかし、この推奨は全てのケースに当てはまるわけではない。本稿は、2026年時点での Postgres と NoSQL の選択判断を、具体的なワークロード特性で整理する。
要点
Postgres は JSONB、パーティショニング、論理レプリケーション、多様なインデックス種の成熟により、以前 NoSQL が担っていたユースケースの多くをカバーできるようになった。ただし、水平書き込みスケール、グローバル低レイテンシ、大量のセッションデータのような書き込み優位ワークロードでは、NoSQL または NewSQL の選択が依然として合理的である。「デフォルト Postgres」は正しい一般則だが、限界を過信すべきではない。
Postgres が近年獲得した能力
Postgres が「NoSQL 代替」として機能するようになった主な要因は、以下の機能拡張である。
- JSONB データ型： Postgres 9.4（2014）以降、JSONB がネイティブサポート。GIN インデックスによる高速な key/path 検索、部分更新、パス式検索が可能。
- 宣言的パーティショニング： Postgres 10（2017）で導入され、以降のバージョンで大幅に強化。時系列データやテナント分離のユースケースで実質的な代替になる。
- 論理レプリケーション： Postgres 10 で導入、後方バージョンで段階的に強化。テーブル単位の選択的レプリケーションが可能。
- 拡張機能エコシステム： pgvector（ベクトル検索）、TimescaleDB（時系列）、Citus（分散化）、PostGIS（地理空間）などが、それぞれ NoSQL 系専門 DB の代替として使えるように成熟。
これらの能力を組み合わせることで、以前は MongoDB、Elasticsearch、Redis、Cassandra などを個別に採用していたユースケースの多くを、Postgres 単体でカバーできる。運用コストとしても、複数 DB の運用より単一 DB の運用のほうが低いことが多い。もっとも、拡張機能の運用は本体とは別の学習曲線を要求するため、単純に「一つの DB」と割り切れるわけではない。
Postgres の限界と NoSQL が合理的なユースケース
Postgres で対応できない、あるいは対応にコストがかかりすぎるユースケースは以下のようなものである。
- 水平書き込みスケール： 単一ノード書き込み性能は Postgres でも十分高いが、それを超えるとシャーディングが必要になる。Citus のような拡張はあるが、運用複雑性は増す。Cassandra や ScyllaDB、または DynamoDB のような設計は、この領域を最初から想定している。
- グローバル低レイテンシ： 複数リージョンで低レイテンシ書き込みを実現するには、CockroachDB、Spanner、YugabyteDB などの NewSQL が構造的に有利。Postgres の論理レプリケーションは非同期を前提とする。
- 大量のセッションデータ、キャッシュ： Redis や Memcached のようなインメモリストアが、レイテンシとコストの両面で優位。Postgres をキャッシュとして使うのは実質的に非効率。
- ドキュメント指向の柔軟性が第一： スキーマが激しく変化する初期段階では、MongoDB や Firestore の柔軟性が開発速度に効く。JSONB でも近い柔軟性は得られるが、開発者体験が別物。
Aphyr（Kyle Kingsbury）の Jepsen シリーズは、分散データベースの一貫性挙動を実測で検証しており、単純な「CAP 定理の教科書的分類」を超えた実装差を示してきた。実際の選択では、こうした実測レポートを参照するのが妥当である。技術基盤の選択が長期投資であることは、AI チップ選択（AI チップ選択とベンダーロックインのコスト構造）と共通する構造である。
組織能力との適合
技術選択で見落とされがちなのが、運用組織の能力との適合である。Postgres の運用は数十年の蓄積があり、DBA 人材、モニタリングツール、バックアップ・リストア手順が広く知られている。NoSQL 系 DB の運用は、それぞれ独立の学習曲線を持ち、労働市場での人材確保も専門化する。
スタートアップ段階では、単一の DB を深く運用できる状態のほうが、複数の DB を浅く運用する状態より事業リスクが小さい。「デフォルト Postgres」の推奨は、この組織能力の観点からも支持される。もっとも、事業スケール後にワークロード特性が Postgres の限界に達した場合、それを認めて別技術を導入する判断力は保っていたい。デザインシステムの粒度判断（デザインシステムのスケーラビリティ）と同様に、「単一の正解」を求めず、状況に応じた再評価の余地を残す設計が長期的に効く。
結論
2026年時点の Postgres は、以前想定されていたよりずっと広い範囲のワークロードをカバーできる。しかし、これは NoSQL の全面的な陳腐化を意味しない。書き込み優位のワークロード、グローバル分散、極端に高いスループット要求では、専用 DB の選択が依然として合理的である。「デフォルト Postgres」は初期の正しい選択だが、限界を認識せずに全てを Postgres に押し込む姿勢は、後年の再設計コストを増やす。技術選択の質は、正解を選ぶことより、限界を認識することで決まる場面が多い。
参照
- PostgreSQL Global Development Group. 公式ドキュメントおよびリリースノート（9.4〜最新版）。
- Kingsbury, Kyle (Aphyr). “Jepsen” 分析シリーズ。分散 DB の一貫性実測。
- Pavlo, Andy. “Database Systems” 講義シリーズ（Carnegie Mellon University）。
- DB-Engines. 継続的な DBMS ランキング。市場採用の推移。