PostgreSQL ─ 完璧主義者たちの 40 年戦争

壊れないことへの執着が、AI時代の万能基盤を生んだ

AIは、極めて自然に嘘をつく。

生成AI、RAG、Vector DB、Agent。
システムは賢くなった。
だがその代わりに、「どこに真実があるのか」が見えにくくなっている。

そんな時代に、50年前の思想であるRDBが、再び静かに存在感を増し始めている。

PostgreSQL。
長い間「遅い」と言われ続けながら、“壊れないこと”を異様なまでに重視し続けてきたデータベース。

本稿は、その40年を、
単なるDB進化史ではなく、

「人類はなぜ周期的に“正しさ”へ回帰するのか」

という視点から描く、技術文明論である。

プロローグ：AI の嘘と、人類の渇望
第1章：Ingres の亡霊 ─ Berkeley が見た次世代DBの夢
第2章：遅い。でも壊れない ─ MySQL 全盛期に背負った誤解
第3章：Web企業は、なぜ PostgreSQL を選び直したのか
第4章：NoSQL が教えてくれたこと ─ JSONB と拡張機能の逆襲
第5章：AI 時代の PostgreSQL ─ pgvector と“全部別 DB”疲れ
エピローグ：循環の証明 ─ 人類はなぜ、“正しさ”へ回帰するのか

プロローグ：AI の嘘と、人類の渇望

2020年代の開発現場は、奇妙な時代に入っている。

かつてエンジニアたちが恐れていたのは、CPU不足やメモリ不足だった。
だが今、現場を支配しているのは、もっと曖昧で、もっと説明しづらい不安だ。

「なぜ昨日まで動いていたものが、今日は壊れているのか」

その問いに、誰も即答できない。

LangChain。
AI Agent。
MCP。
Tool Calling。
Vector DB。
Embedding。
RAG。

新しい技術が次々と生まれ、開発者たちはそれらを繋ぎ合わせながら、巨大なシステムを組み上げていく。

しかし、その全体像を、本当に理解している人間はどれほどいるのだろうか。

Docker コンテナは増殖し、ベクターストアは乱立し、キャッシュは幾重にも重なり、AI エージェント同士が互いにツールを呼び出し続ける。

システムは「賢く」なった。
その代わりに、「何が真実なのか」が見えにくくなった。

生成AIは、驚くほど自然に嘘をつく。

いや、正確には違う。
AI は「嘘をつこう」としているわけではない。

それは、もっと厄介な存在だ。

AI は、“もっとも確率の高そうな答え”を、極めて流暢に話してしまう。

その結果、開発者たちは今、新しい種類の障害と戦っている。

古いシステム障害は、比較的単純だった。

サーバーが落ちる。
ディスクが壊れる。
SQL が詰まる。
ログを追えば、原因はどこかに存在した。

しかし AI 時代の障害は違う。

ベクトル検索の結果が古い。
Embedding の更新がズレている。
RAG の参照元が壊れている。
Agent が古いツール定義を掴んでいる。

しかも厄介なのは、システム全体は“それっぽく動いてしまう”ことだ。

間違っているのに、自然に見える。
壊れているのに、会話は成立する。

それが、今のAIシステムの恐ろしさだった。

そして、その混沌の中で、エンジニアたちは少しずつ、ある古い価値観を思い出し始めている。

「やはり、最後は“正しいデータ”が必要なのではないか？」

それは、一見すると時代遅れの発想に見える。

2000年代、Webの世界は「速度」が正義だった。

まず動け。
スケールしたら考えろ。
JOIN は重い。
正規化は古い。

LAMP スタックは、その思想の象徴だった。

実際、あの時代に MySQL が果たした役割は大きい。
PHP と MySQL は、Web を一気に民主化した。

個人サイト。
掲示板。
ブログ。
EC。
CMS。

高価な商用システムでなければ作れなかったものを、安価なレンタルサーバー上で誰もが構築できるようになった。

WordPress が MySQL を採用していなければ、あの時代の Web 文化は、ここまで爆発しなかったかもしれない。

だが、Web が「遊び」から「社会基盤」へ変わり始めたとき、空気が少しずつ変わり始める。

課金。
在庫。
金融。
会員管理。
SaaS。

「壊れてもいい」では済まない世界。

そこで、再び注目され始めたのが、「正しさ」を異常なまでに重視し続けてきたデータベースたちだった。

PostgreSQL は、その象徴だった。

長い間、「遅い」と言われ続けてきた。
融通が利かないとも言われた。
派手さもなかった。

しかし、その内部には、一つの頑固な思想が流れていた。

「核心は、壊してはいけない」

トランザクション。
一貫性。
監査性。
永続性。

どれだけ外側が変化しても、その土台だけは手放さなかった。

そして皮肉なことに、その“頑固さ”こそが、後に PostgreSQL をもっとも柔軟な存在へ変えていく。

JSON。
GIS。
時系列。
分散。
ベクトル検索。

普通なら、柔軟性を増せば壊れやすくなる。
しかし PostgreSQL は違った。

核心を壊さなかったからこそ、外側を自由に拡張できた。

AI 時代に入り、私たちは再び「土台」を求め始めている。

それは、AI を否定するためではない。
むしろ逆だ。

AI を本当に社会基盤として使うためには、その下に「壊れないもの」が必要になった。

『PostgreSQL ─ 完璧主義者たちの40年戦争』は、単なるデータベースの歴史ではない。

これは、

「人類はなぜ、周期的に“正しさ”へ回帰するのか」

という、技術文明そのものの物語である。

第1章：Ingres の亡霊 ─ Berkeley が見た次世代DBの夢

1970年代後半、データベースはまだ「巨大企業の専用機械」に近い存在だった。

IBM。
Oracle。
DEC。

コンピュータそのものが高価で、データは限られた組織だけが扱える“資産”だった時代である。

当時のデータベースは、いまのように気軽に触れるものではない。
ベンダーごとに仕様は閉じ、実装はブラックボックス化され、内部がどう動いているかを知る術はほとんどなかった。

それは「完成された製品」だった。

だが、大学の研究者たちは、その状況に強い違和感を抱いていた。

「データとは、本来もっと自由に扱えるべきものではないのか？」

カリフォルニア大学バークレー校で始まった Ingres プロジェクトは、そうした空気の中から生まれている。

現在では PostgreSQL の源流として語られることが多いが、当時の Ingres は単なる「OSS DBの祖先」ではない。
それは、商用データベースに対する、かなり急進的な思想運動だった。

データベースは単なる保存箱ではない。
データは、厳密な構造を持つべきだ。
そして、その構造は人間が理解できる形で記述されなければならない。

そうした思想が、後のリレーショナルモデルへ繋がっていく。

いまでは当たり前になった SQL も、当時はまだ「未来の概念」に近かった。

テーブル。
行。
列。
JOIN。

現在のエンジニアにとっては呼吸のような概念だが、当時はそれ自体が革新的だったのである。

特に重要だったのは、「データの整合性をシステム側が保証する」という発想だった。

いまの感覚では当然に聞こえる。
しかし当時、多くのシステムでは整合性は“運用で頑張るもの”だった。

入力ミス。
重複。
更新競合。

それらは日常的に起きていた。

リレーショナルモデルは、そこへ初めて「数学的な秩序」を持ち込んだ。

そして、この思想に強く惹かれたのが、後の PostgreSQL に繋がる研究者たちだった。

だが、ここで歴史は一つの皮肉を迎える。

Ingres は成功してしまったのである。

成功した技術は、商業へ飲み込まれる。

それは避けられない。

Ingres の思想は企業へ流れ込み、商用製品化され、やがて巨大な市場の一部になっていく。

もちろん、それ自体は悪ではない。
むしろ、研究成果が社会へ普及するという意味では、極めて健全な流れだった。

だが、その過程で少しずつ変質していくものがあった。

「理想」と「現実」の距離である。

市場は厳密性だけを求めない。

速度。
価格。
導入の容易さ。
営業。
サポート。
互換性。

製品になるということは、そうした現実と折り合いをつけるということだった。

そして、その折り合いの中で、多くのシステムは少しずつ“妥協”を覚えていく。

実際、1980〜90年代のデータベース市場は、現在とは比較にならないほど“ベンダー主導”だった。

仕様は企業が決める。
機能追加の優先順位も企業が決める。
ユーザーは、その巨大な流れに従うしかなかった。

そうした時代の中で、Postgres プロジェクトは少し異質だった。

それは「市場を制圧するための製品」ではなかった。

むしろ逆である。

「もし、利益や営業都合を一旦脇へ置いて、“正しいデータ管理”だけを追求したら、何ができるのか？」

その問いを、異常なまでに真面目に掘り続けたプロジェクトだった。

だから Postgres は、最初から“速さ”を最優先にはしていない。

派手なデモもない。
巨大な広告もない。
「世界を変える」と叫ぶスタートアップ文化とも遠かった。

だが、その代わりに、ある執念だけは失わなかった。

「核心は壊さない」

データの整合性。
トランザクション。
永続性。
一貫性。

どれだけ周囲の流行が変わっても、その核だけは絶対に手放さない。

当時は、それが少し時代遅れにも見えた。

80年代後半から90年代にかけて、コンピュータの世界は「より速く、より軽く、より大量に」へ向かっていたからだ。

だが、後になって振り返ると、この“頑固さ”が PostgreSQL の運命を決定づけることになる。

なぜなら、核心を壊さなかったシステムだけが、後に外側を自由に拡張できたからである。

JSON。
GIS。
分散。
ベクトル検索。

PostgreSQL が後年、それらを次々と飲み込んでいけた理由は、この時代にすでに決まっていた。

それは「保守的だった」からではない。

むしろ逆だ。

核心を壊さないという強烈な制約があったからこそ、外側を大胆に変え続ける自由を持てたのである。

その思想は、まだ誰にも理解されていなかった。

少なくとも、Web が熱狂へ向かう次の時代までは。

第2章：遅い。でも壊れない ─ MySQL 全盛期に背負った誤解

2000年代初頭。

インターネットは、明らかに何かが変わり始めていた。

個人ホームページの時代が終わり、Web は「読む場所」から「参加する場所」へ変わり始める。

掲示板。
ブログ。
SNS。
コメント欄。
ショッピングカート。

ユーザー自身がデータを書き込む時代が始まった。

そして、その爆発を支えていたのが、LAMP という奇妙なまでに完成された組み合わせだった。

Linux。
Apache。
MySQL。
PHP。

いま振り返れば、どれも少し粗削りだった。
だが、安かった。
軽かった。
そして、異常なほど動いた。

特に MySQL の存在感は圧倒的だった。

当時の MySQL は、速かった。

本当に速かった。

特に MyISAM 時代の MySQL は、「とにかくレスポンスを返す」ことにおいて、強烈な体感速度を持っていた。

SELECT が軽い。
PHP から叩きやすい。
レンタルサーバーで普通に動く。

そして何より、

「難しくない」。

これが大きかった。

当時の Web 開発者の多くは、必ずしも“データベース専門家”ではない。

CGI 制作者。
Web デザイナー。
個人開発者。
学生。
小規模事業者。

そうした人々が、「動くWebサービス」を初めて自力で作れた時代だった。

だから当時の MySQL は、単なるデータベースではない。

それは、

「Web の民主化装置」

だった。

WordPress が爆発的に広がった背景にも、この空気がある。

もし WordPress が PostgreSQL を前提に設計されていたら、あの時代のレンタルサーバー文化は、ここまで決定的なものにはならなかったかもしれない。

安価な共有サーバー。
簡単インストール。
PHP のコピペ文化。

そのすべてが、MySQL と強く結びついていた。

だから、当時 PostgreSQL が“重い”と言われていたのは、ある意味では当然だった。

実際、重かったのである。

少なくとも、「まず動かしたい」という2000年代Webの欲望とは、あまり噛み合っていなかった。

当時の空気を覚えている人なら、こんな言葉に聞き覚えがあるはずだ。

「JOIN は重いから使うな」

「正規化なんて実運用では無理」

「スケールしたら考える」

「まず動け」

いま見ると乱暴だ。
だが、あの時代には、あの時代なりの必然性があった。

Web サービスは、まず公開しなければ始まらなかった。

スピードこそが競争力だった。

実際、その思想はインターネットを爆発的に成長させた。

だから、MySQL は間違っていなかった。

むしろ、あの時代に必要だった。

問題は、その成功があまりにも巨大だったことだ。

Web は次第に「遊び」では済まなくなる。

課金。
EC。
在庫。
会員情報。
金融。
SaaS。

データが「失われてもいいもの」ではなくなっていった。

すると、少しずつ空気が変わり始める。

深夜、障害対応に追われる運用担当者たち。

クラッシュ後、repair が終わらない MyISAM テーブル。

ロック競合。

増え続ける冗長カラム。

スケールのために継ぎ足され続けたキャッシュ層。

「まず動け」で始まったシステムは、巨大化するにつれて、“誰も全体像を理解できないもの”へ変わっていった。

そしてその頃から、少しずつ再評価され始める存在があった。

PostgreSQL である。

だが、それは「速くなったから」だけではない。

もちろん PostgreSQL 側も進化していた。

クエリ最適化。
MVCC の成熟。
WAL の強化。

性能差そのものも、徐々に縮まっていく。

しかし本質は、そこではなかった。

重要だったのは、

「壊れない」

という感覚だった。

PostgreSQL は、最初から一貫して、

「データの正しさを、後回しにしない」という思想を持っていた。

トランザクション。
整合性。
永続性。

それらを、“後で追加する機能”として扱わなかった。

当時は、それが「遅さ」に見えた。

だが、Web が社会基盤へ変わるにつれ、その“遅さ”は別の名前で呼ばれるようになる。

「信頼性」

である。

実際、MySQL 自身も変わっていく。

InnoDB の普及は、その象徴だった。

高速さだけでは、世界を支えられない。

MySQL 自身が、少しずつ「壊れない方向」へ舵を切り始めていた。

皮肉な話だが、その瞬間から、PostgreSQL との差は急速に縮まり始める。

そして、この流れの中で、もう一つの異端が静かに広がっていく。

SQLite だった。

ファイルベース。
サーバーレス。
小さい。
だが、異様に速い。

しかも、驚くほど壊れにくい。

当時、多くの開発者にとって SQLite は「組み込み用途の変わり種」に近かった。

だが後になって振り返ると、SQLite もまた、

「シンプルさと整合性を両立しようとした思想」

の系譜に属していた。

巨大サービスは PostgreSQL へ。

小さなサービスやローカル環境は SQLite へ。

そして MySQL は、「Web を爆発的に普及させた王」として歴史に刻まれていく。

2000年代の熱狂は、確かに世界を変えた。

だが、その熱狂の果てに、人類は再び“壊れないもの”を求め始める。

それが、次の時代の始まりだった。

第3章：Web企業は、なぜ PostgreSQL を選び直したのか

2010年代。

Web は、もはや「新しい文化」ではなくなっていた。

人々は、日常そのものをインターネットの上へ置き始める。

写真。
会話。
決済。
仕事。
位置情報。
生活履歴。

Web サービスは、「便利なおもちゃ」から「社会基盤」へ変わりつつあった。

そして、その変化は、データベースへ静かに重圧をかけ始める。

2000年代のシステムは、とにかく速く成長することを優先していた。

まず公開する。
ユーザーを集める。
スケールは後で考える。

その思想は、スタートアップ文化と非常に相性が良かった。

実際、多くの成功企業は、その速度によって生まれている。

だから当時の判断は間違っていない。

だが、問題は「成功したあと」だった。

サービスが巨大化すると、システムは別の顔を見せ始める。

複雑な JOIN。
肥大化したキャッシュ。
継ぎ足し続けたシャーディング。
増殖する read replica。
誰も全体を把握できない ORM。

「まず動け」で積み上げられた構造は、成長するほどに“変更できないもの”へ変わっていった。

障害は減らない。

むしろ、サービスが大きくなるほど、障害の影響範囲は広がる。

しかも厄介なのは、多くのシステムが“完全には壊れない”ことだった。

一部だけが古い。
一部だけが同期ズレする。
一部だけが整合しない。

それでもサービス自体は動いてしまう。

この「半分壊れている状態」は、2000年代よりもむしろ2010年代の運用現場を苦しめることになる。

そして、この頃からエンジニアたちは、少しずつ別の価値を求め始める。

「変更できること」

である。

単に速いだけでは足りない。

後から修正できる
スキーマ変更に耐える
複雑な問い合わせを書ける
データ整合性を保てる
長期運用できる

そうした“運用の持続性”が、急速に重要になっていった。

この空気の変化と共に、PostgreSQL は静かに存在感を増していく。

興味深いのは、その広がり方だった。

それは、派手なマーケティングではない。

「巨大企業が採用！」

という単純な話でもない。

むしろ、

「現場が、静かに PostgreSQL を選び始めた」

という広がり方だった。

特に象徴的だったのが、Rails コミュニティとの結びつきである。

Ruby on Rails は、2000年代後半から2010年代にかけて、

「開発速度を最大化する文化」

を強く推し進めた。

だが、その文化は単なる“雑な高速開発”ではなかった。

むしろ逆である。

Rails の世界では次第に、

「あとで壊れない設計」

への意識が強くなっていく。

マイグレーション。
ORM。
テスト。
リファクタリング。

コードを継続的に改善し続ける思想。

そこに PostgreSQL の思想が噛み合った。

複雑なクエリ。
トランザクション。
堅牢な整合性。

「あとで育て続けるシステム」を前提にした時、PostgreSQL は非常に扱いやすかった。

Heroku が PostgreSQL を強く推したのも、この流れと無関係ではない。

Heroku は単に PaaS を売っていたわけではない。

あれは、

「運用を簡単にしたい開発者」

の欲望を吸い上げていた。

そして、その欲望の先に PostgreSQL があった。

AWS の存在も大きい。

RDS for PostgreSQL が広く浸透し始めたことで、

「PostgreSQL は運用が重い」

という古い印象は急速に崩れていく。

ここで重要なのは、クラウドが単に“便利”だったことではない。

クラウドによって、

「DB選定の基準」

そのものが変わったのである。

以前は、

「どれだけ速く動くか」

が重要だった。

だがクラウド時代には、

長期運用しやすいか
機能追加しやすいか
障害時に戻せるか
将来的に複雑化へ耐えられるか

が重要になる。

つまり、Web の成熟そのものが、

「Consistency を重視する世界」

へ移行していった。

Instagram の事例も象徴的だった。

後年、「巨大サービス = MySQL」という印象が強かった時代において、Instagram はかなり早い段階から PostgreSQL を採用している。

これは単なる偶然ではない。

写真共有サービスは、一見すると単純に見える。

しかし実際には、

タイムライン
関係性
メタデータ
検索
通知
集計

など、極めて複雑な問い合わせが大量に発生する。

単純な Key-Value 的設計だけでは限界が来やすい。

そのとき、PostgreSQL の

「複雑性を、複雑なまま扱える」

という性質が強みになる。

ここが重要だった。

PostgreSQL は、「単純化して高速化するDB」ではない。

むしろ、

「複雑な現実を、整合性を保ったまま扱うDB」

だった。

だからこそ、Web が社会基盤化するほど、その価値が再浮上していく。

そしてこの頃から、RDB 世界の勢力図も静かに変わり始める。

超巨大・高信頼領域には Oracle。

Web の民主化を支えた MySQL。

そして、

「長期運用される現代的システムの土台」

としての PostgreSQL。

さらに、ローカル・組み込み・小規模用途では SQLite。

この構図が、少しずつ見え始めていた。

もちろん、この時点ではまだ誰も、

PostgreSQL が後に JSON や AI まで飲み込んでいくとは想像していない。

だが、その準備はすでに始まっていた。

なぜなら PostgreSQL は、

「核心を壊さずに、複雑性を扱う」

という思想を、最初から捨てていなかったからである。

第4章：NoSQL が教えてくれたこと ─ JSONB と拡張機能の逆襲

2010年代中盤。

技術業界は、再び熱狂していた。

今度の主役は、NoSQL だった。

MongoDB。
Cassandra。
Redis。
HBase。
CouchDB。

イベント登壇では、

「RDBMS はもう古い」

という言葉が、半ば当然のように語られていた。

スキーマレス。
水平分散。
最終的整合性。
巨大スケール。

それらは、当時のインターネットが抱えていた課題に、確かに応えていた。

実際、NoSQL は必要だった。

そこは誤解してはいけない。

2010年代のサービス規模は、2000年代とは比較にならない。

スマートフォンの普及によって、Web は「数万人」ではなく、「数億人」が使う世界へ突入していた。

従来型 RDB だけでは、物理的に耐えられない領域が確かに存在した。

だから、NoSQL の台頭は自然だった。

特に重要だったのは、

「データ構造を後から変えられる」

という自由だった。

JSON が象徴していたのは、単なるデータ形式ではない。

それは、

「未来がまだ分からない時代の柔軟性」

そのものだった。

スタートアップは、毎週仕様が変わる。

ユーザー行動も読めない。

その状況で、厳密なスキーマを先に固定することは、確かに重荷でもあった。

だから当時の、

「とりあえず JSON で持てばいい」

という空気にも理由がある。

実際、その自由は、多くの新しいサービスを生み出した。

だが同時に、その自由は別の問題も連れてくる。

「どこまでが正しいデータなのか分からない」

という問題だった。

柔軟性は、時に“曖昧さ”へ変わる。

最初は便利だった JSON フィールドが、数年後には誰も構造を説明できなくなる。

サービスごとに異なるキー。

微妙に違う null の扱い。

同期されないキャッシュ。

古い API。

そして、

「全部動いているように見える」

ことが、さらに問題を難しくする。

これは NoSQL が悪かったという話ではない。

むしろ逆だ。

NoSQL は、

「RDB が苦手だった現実」

を、極めて正直に突きつけた。

巨大分散。
柔軟なデータ。
高速書き込み。
スキーマ進化。

それまでの RDB 世界は、ある意味で“整いすぎていた”。

NoSQL は、その外側に存在する混沌を暴き出したのである。

そして興味深いのは、PostgreSQL の反応だった。

PostgreSQL は、この流れに正面から反発しなかった。

「NoSQL は邪道だ」

とも言わなかった。

むしろ、静かに吸収を始める。

これが PostgreSQL の異様なところだった。

普通、古いシステムは、新しい流行に抵抗する。

しかし PostgreSQL は違う。

JSONB。

この機能が象徴しているのは、単なる JSON 対応ではない。

それは、

「柔軟性を、整合性の中へ持ち込む」

という思想だった。

これはかなり危険な挑戦でもあった。

柔軟性を増せば、普通は壊れやすくなる。

だが PostgreSQL は、

「核心を壊さない」

という前提を捨てなかった。

トランザクション。
整合性。
監査性。

その上に JSON を載せた。

ここが重要だった。

PostgreSQL は、

「NoSQL を否定した」

のではない。

むしろ、

「NoSQL 的柔軟性を、ACID の内部へ取り込んだ」

のである。

この時点で、PostgreSQL は少しずつ“単なるRDB”ではなくなり始める。

さらに興味深いのが、Extension 文化の爆発だった。

PostGIS。
TimescaleDB。
Citus。

これらは、昔なら「専用DBが必要」と言われていた領域である。

GIS。
時系列。
分散。

本来なら別システムへ分裂していたはずの機能が、PostgreSQL の内部へ吸収され始める。

しかも、ただ詰め込んでいるわけではない。

それらが、

「同じトランザクションの中で動く」

ことに意味があった。

ここで、少しずつ空気が変わる。

かつては、

「用途ごとに最適なDBを選ぶ」

ことが“正しい設計”とされていた。

Polyglot Persistence。

その言葉が流行した時代である。

だが現実には、

DB が増える
運用が増える
同期が増える
障害点が増える

という問題も同時に膨らんでいった。

システムは賢くなる。

しかし、人間は全体を理解できなくなる。

そして現場では、少しずつ別の感情が広がり始める。

「できれば、まとめたい」

という疲労感である。

この頃から PostgreSQL は、単なる“堅牢なRDB”ではなく、

「複雑性を統合する器」

として見られ始める。

しかも、その統合は、

“何でもアリ”

ではなかった。

そこが PostgreSQL の奇妙なところだった。

自由を許しながら、最後は整合性へ戻す。

柔軟なのに、監査できる。

複雑なのに、トランザクションが壊れない。

この矛盾した性質が、後の AI 時代で決定的な意味を持ち始める。

なぜなら次の時代、人類はさらに巨大な複雑性へ突入するからである。

第5章：AI 時代の PostgreSQL ─ pgvector と“全部別 DB”疲れ

2020年代後半。

ソフトウェア開発の風景は、再び大きく変わり始めていた。

今度の中心にいたのは、AI だった。

ChatGPT の登場以降、世界中の開発者が「AI を組み込んだサービス」を作り始める。

要約。
検索。
分類。
対話。
推薦。
自動化。

あらゆるシステムに、“言語理解”が接続され始めた。

そして、その裏側では、新しいインフラが急速に増殖していく。

Embedding。
Vector DB。
RAG。
Agent。
Tool Calling。
Workflow Engine。

一時期の AI スタックは、まるで 2010 年代の NoSQL 爆発を圧縮再生しているようだった。

新しいベクターデータベースが次々と登場する。

「AI 時代には専用 DB が必要だ」

そんな空気が、半ば当然のように語られていた。

実際、それにも理由はある。

従来の RDB は、「意味の近さ」を扱うようには設計されていなかった。

AI 時代では、

「この文章に近い概念は何か」

を検索する必要がある。

そこでベクトル検索という新しい発想が必要になった。

だから Vector DB の誕生自体は自然だった。

問題は、その後だった。

AI システムは、急速に複雑化していく。

RDB。
Vector DB。
全文検索。
Redis。
Object Storage。
Workflow Engine。

さらにその上で、

LangChain。
Agent Framework。
MCP。
Tool Registry。

システムは“賢く”なる。

しかし同時に、

「誰も全体を理解できない」

状態へ近づいていった。

しかも、AI システム特有の厄介さがある。

普通の障害は、比較的分かりやすい。

落ちる。
止まる。
500 エラーになる。

だが AI システムは違う。

少し古い情報を返す。
Embedding が更新されていない。
古いベクトルを参照している。
別キャッシュの結果が混ざる。

それでも会話は成立してしまう。

つまり、

“壊れ方が曖昧”

なのである。

ここが恐ろしかった。

しかも AI は、非常に流暢に間違う。

人間は、自然な文章に騙される。

すると問題は、「検索精度」ではなくなってくる。

最終的には、

「どのデータを、どこまで信用できるのか」

という話へ戻っていく。

ここで、再び PostgreSQL が浮上し始める。

しかも今回は、少し違う形だった。

JSONB の時代、PostgreSQL は

「柔軟性を取り込める RDB」

として再評価された。

だが AI 時代には、

「複雑性を統合できる基盤」

として見られ始める。

その象徴が pgvector だった。

興味深いのは、pgvector が“革命的に新しい”わけではなかったことだ。

むしろ逆である。

PostgreSQL の内部へ、

「ベクトル検索」

を自然に埋め込んだ。

ただ、それだけだった。

だが、その“ただそれだけ”が大きかった。

知識ベース。
ユーザー情報。
監査ログ。
権限。
Embedding。

それらを、

「同じトランザクション世界」の中で扱える。

ここに強烈な価値が生まれ始める。

特に企業システムでは顕著だった。

AI 単体なら動く。

しかし、

誰が参照したか
いつ更新したか
元データは何か
本当に最新か

まで含めると、一気に“業務システム”になる。

そして業務システムには、最後に必ず

「監査」

がやってくる。

AI がどれほど賢くなっても、

「なぜその答えを返したのか」

を説明できなければ、社会基盤にはなりにくい。

すると結局、

「正しいデータを、追跡可能な形で保持したい」

という要求へ戻っていく。

ここで PostgreSQL の思想が、妙に現代と噛み合い始める。

しかも皮肉なのは、

AI が進化するほど、

「シンプルな土台が欲しい」

という欲求が強くなっていくことだった。

2010年代、人類は

「用途ごとに最適な DB を分ける」

方向へ進んだ。

しかし 2020年代後半、人々は逆方向を向き始める。

「できれば減らしたい」

のである。

運用対象を。

同期を。

整合確認を。

“どこが壊れているか分からない巨大システム”

を。

この感覚は、2000年代後半の「MySQL 運用地獄」に少し似ている。

複雑化が進みすぎると、人類は再び“土台”を求め始める。

PostgreSQL は、そこへ非常に奇妙な形で戻ってきた。

もはや単なる RDB ではない。

Document DB 的でもあり、
検索エンジン的でもあり、
GIS 的でもあり、
Vector DB 的でもある。

しかし、その中心には昔と同じものが残っている。

ACID。

整合性。

トランザクション。

監査性。

つまり PostgreSQL は、

「全部入り」

になったのではない。

最後まで、

「正しいデータを扱う」

ことを捨てなかった。

だからこそ、外側を際限なく拡張できたのである。

そして今、AI 時代は再び問いを突きつけている。

人類は、「賢さ」だけを求めるのか。

それとも、「正しさ」も必要なのか。

PostgreSQL の40年は、その問いに対する、一つの静かな返答だった。

エピローグ：循環の証明 ─ 人類はなぜ、“正しさ”へ回帰するのか

振り返ってみると、IT の歴史は奇妙なほど同じことを繰り返している。

単純化。
普及。
爆発。
複雑化。
疲弊。
再統合。

メインフレームから UNIX へ。
モノリスから Web へ。
オンプレミスからクラウドへ。
そして今、AI と Agent の時代へ。

技術は進歩する。

だが、人間が直面する悩みは、驚くほど変わらない。

「速くしたい」

「自由にしたい」

「もっと柔軟にしたい」

その欲望が、新しい技術を生む。

だが自由は、やがて複雑性を連れてくる。

システムは巨大化し、依存関係は増殖し、誰も全体を理解できなくなる。

そして人類は、疲れる。

その瞬間、再び求められるのが、

「壊れない土台」

だった。

PostgreSQL の歴史は、まさにその循環の歴史だった。

流行の中心にいたことは、一度もない。

2000年代、Web の主役は MySQL だった。

NoSQL 時代には、

「RDBMS は古い」

と何度も言われた。

AI 時代には、

「Vector DB がすべてを置き換える」

という空気もあった。

だが PostgreSQL は、そのどれにも真正面から対抗しなかった。

否定しなかった。

静かに観察し、必要なものだけを取り込み続けた。

JSON。
GIS。
時系列。
分散。
ベクトル検索。

その姿は、一見すると節操がない。

だが実際には、極めて一貫している。

PostgreSQL は、

「何でもできるDB」

を目指していたわけではない。

むしろ逆だ。

「正しさを壊さずに、どこまで拡張できるか」

を追い続けていた。

だからこそ、その拡張には奇妙な安定感がある。

JSON を扱っても、トランザクションは壊れない。

Vector を扱っても、監査性を失わない。

柔軟なのに、最後は整合性へ戻ってくる。

この感覚は、AI 時代に入って急速に重みを増し始める。

なぜなら AI は、人類史上初めて、

「極めて賢く、極めて自然に間違う存在」

だからだ。

これまでのコンピュータは、不正確ではあっても、不自然だった。

クラッシュする。
止まる。
エラーを吐く。

だが AI は違う。

間違っていても、自然に見える。

それが厄介だった。

だから今、技術の世界では奇妙な逆流が始まっている。

AI は自由を増やした。

だがその結果、人類は再び、

「どこに真実を置くのか」

を問われ始めている。

RAG。
Vector Search。
Agent Workflow。

それらが高度化するほど、

元データは何か
更新履歴は追えるか
本当に最新か
監査できるか

という、“古典的な問い”が復活してくる。

そして、その問いに最も長く向き合ってきたのが、RDB の世界だった。

特に PostgreSQL は、その中心で、

「流行に飲まれない」

という、ある種異様な態度を取り続けてきた。

これは、保守的だったからではない。

むしろ逆である。

核心を壊さないという制約を、自らに課していたからだ。

普通、自由を増やせば壊れやすくなる。

だが PostgreSQL は、

「核心を固定したまま、外側を変化させる」

という方向へ進んだ。

それは、一種の文明的な態度でもある。

変化を拒絶しない。

しかし、土台は捨てない。

この姿勢は、AI 時代のシステム設計そのものに重なり始めている。

私たちは今後、さらに多くの AI を使うだろう。

Agent は増える。

自動化も進む。

生成 AI は、さらに自然に、さらに人間らしくなる。

だがその時代に、本当に必要になるのは、

「もっと賢い嘘つき」

ではない。

その下で、

「最後に真実を保持する土台」

をどう維持するかだった。

PostgreSQL の40年戦争は、単なるデータベースの歴史ではない。

それは、

「人類は、どこまで自由を求め、どこで正しさへ戻るのか」

という、技術文明そのものの記録だった。

そして今、その循環は再び始まろうとしている。

AI が嘘をつくほどに、人類は“真実”を欲する。

だからこそ、50年前に生まれた RDB の思想は、再び未来へ接続され始めているのである。