2026年、ただPostgresを使おう（It's 2026. Just Use Postgres）
(tigerdata.com)核心的な主張
- 「適切なツールを使え」という長年の助言は、むしろデータベースの乱立（sprawl）を招き、運用地獄を生み出す。2026年のAIエージェント時代には、1つのデータベースですべてを処理することが圧倒的に有利だ。結論から言えば → 大半（99%）の会社はPostgres 1つで十分だ。
なぜ今、Postgres 1つで行くべきなのか？
- AIエージェントはテストDBをすばやく立ち上げ、フォークし、デバッグできなければならないが、複数のDB（Pinecone + Elasticsearch + Redis + MongoDB など）を使うと、それはほぼ不可能になる。
- Postgres 1つなら、バックアップ・監視・セキュリティ・障害復旧の戦略を単一化できる → 認知負荷と隠れたコストが急激に減る。
- 複数のDBを使うと、同期失敗、復旧難易度の爆発的上昇、運用複雑性が7倍に増えるといった問題が現実になる。
Postgresが専用DBを置き換えられる具体的根拠
Postgresの拡張機能は、専用DBと同等またはそれ以上のアルゴリズムをすでに実装している:
- 検索 → pg_textsearch (BM25) → Elasticsearchの代替
- ベクトル検索 → pgvector + pgvectorscale (DiskANN) → Pineconeより28倍高速で75%安価
- 時系列 → TimescaleDB → InfluxDBと同等以上 + 完全なSQL対応
- ドキュメント → JSONB → MongoDB級の性能 + ACID保証
- 地理空間情報 → PostGIS（2001年から標準）
- キュー → pgmq → Kafkaの代替が可能
- そのほか pg_cron、pgai などで大半をカバー
反対意見への反論
- 「特定の作業は専用DBのほうが優れている」 → その通りだが、99%の企業には過剰であり、意味があるのは上位1%の極端なケースだけだ。
- 専用DBベンダーのマーケティングが「right tool」という神話を広めただけで、実際には隠れた運用コストとデータ整合性の崩壊のほうがはるかに大きい。
結論
- まずPostgresから始めよう。
- 必要性が証明されたときにだけ複雑さを追加しよう。
- 2026年には、ただPostgresを使おう。
(Tiger DataはTimescaleDB/pgvectorなどを作っている会社なので多少宣伝色はあるが、主張の論理とベンチマークの根拠はかなり説得力がある。)
9件のコメント
right tool for the jobという言葉は、そもそも会社の規模や保守性の観点、コストまで全部含めて言うものだと思うのですが、いつからあの言葉が特定の作業に特化したツールを使えという意味に解釈されるようになったのか理解できません。昔からそうだったけど、最近は supabase や neon db のようなサービスが、非開発者のバイブコーディングにも向いていて、なおさら良くなった気がする
否定できませんね。
MySQLも最新バージョンでは各種の利便性が改善されていて悪くありませんが、PostgreSQLを使うほうがやはり少し楽ではあります。
クラスターインデックスで性能を最大化したいケースなら、MySQL InnoDBのほうが少し向いているかも？
MySQLではだめですか??
逆に「2026年にはMySQLの使用をやめましょう」という話もあります.. https://optimizedbyotto.com/post/reasons-to-stop-using-mysql/
「Postgresで何でもできる」という趣旨の記事は、定期的に上がってきますね。
Postgres と私たちのビジネスのどちらがより脆弱なのかを考えてみると……
他の内容を排して、純粋に保守の観点だけで見れば利点はありそうですね。
ただ、採用済みの人材、関連ツール、今後採用する人材、そしてこの意見によって生じる組織内の対立まで含めると、本当に良い意見なのかは疑問があります。
絶対的に正しいというよりは、組織の状況に合ったソリューションならそれを選ぶのがよさそうですね（笑）
どんなコメントが積み上がるか見えてしまうのは、それだけ似たような主張についたコメントを脳が学習してしまったせいなんでしょうか（笑）