2027 架構預言:專屬 Vector DB 將淪為過渡玩具，PostgreSQL 迎來底層大反撲

大家都以為 RAG 的解法就是塞一個專屬向量資料庫。但我斷言，2027 年這套「資料庫碎片化」的疊床架屋架構將徹底破產。PostgreSQL 憑藉 pgvector 與硬體指令集的底層融合，正重演當年用 JSONB 屠殺 NoSQL 的歷史。本文從 HNSW 演算法與記憶體頻寬的 First Principles 拆解這波大一統重構潮。

上個月，一位新創的 CTO 興沖沖地向我展示他們最新的 RAG（檢索增強生成）架構圖。Pinecone 存向量，Redis 做快取，PostgreSQL 存關聯資料，旁邊甚至還掛了一個 Neo4j。

老實說，我只覺得頭痛。

這場景我都看膩了。這不就是 2012 年那波「NoSQL 狂熱」的翻版嗎？當時大家也覺得關聯式資料庫已死，要把文件塞進 MongoDB，把 Key-Value 塞進另一個庫。結果呢？PostgreSQL 默默推出 JSONB，用更穩定的事務處理（ACID）把那些號稱「無關聯」的資料吃乾抹淨。

同樣的歷史，現在正在 Vector DB 領域重演。我敢斷言，到了 2027 年，台灣（乃至全球）軟體圈將迎來一波劇烈的「資料庫大一統」重構潮。那些純粹只做向量檢索的專屬 DB，絕大多數都會淪為歷史的過渡期玩具。

The Deep Dive:被過度神話的向量檢索

我們回到第一性原理（First Principles）來看，所謂的「向量資料庫」到底在幹嘛？

簡單來說:存儲一大陣列的浮點數，然後做近似最近鄰（ANN, Approximate Nearest Neighbor）搜尋。現在的主流演算法幾乎都是 HNSW（Hierarchical Navigable Small World）。這不是什麼魔法，它本質上就是一個多層級的機率圖模型，概念非常像 Skip-List 加上底層的 Delaunay 圖。它透過空間換取時間，讓搜尋從線性掃描降到對數時間。

但問題來了。

計算向量距離（不管你是用 Cosine 還是內積）的本質，是高度密集的陣列乘積。在現代硬體架構下，這叫做 SIMD（單指令多資料流）運算。現代 CPU 的 AVX-512 指令集，或是 ARM 的 NEON，算這種東西快得像鬼一樣。這裡的真正硬體瓶頸根本不是「運算能力」，而是「記憶體頻寬（Memory Bandwidth）」。

當你把 Vector DB 獨立出來，你會面臨分散式系統中最致命的兩件事:網路延遲，以及跨網路邊界的 Distributed Join。

想像一下實際的企業場景。你的 user 不會只問「給我語意最接近的文章」。他問的是「給我語意最接近，且『權限屬於部門 A』，並且『日期在過去三天內』的文章」。

如果你用專屬 Vector DB，你通常得先去 Pinecone 撈出 1000 個最相似的 ID，然後透過網路把這 1000 個 ID 丟回你的 PostgreSQL 去做 metadata 過濾。你真的覺得這種在應用層手刻 Nested Loop Join 的行為，具備可擴展性？這簡直是無視 CAP 定理與系統延遲的架構災難。

pgvector 的重砲反擊

這就是為什麼 pgvector（PostgreSQL 的開源擴充套件）一推出，我就知道專屬 Vector DB 的喪鐘敲響了。

起初，pgvector 只支援 IVFFlat（倒排索引），那時的效能確實被 Milvus 這些專屬庫按在地上摩擦。但自從它加入了 HNSW 索引，並且原生支援 CPU 的 SIMD 加速後，遊戲規則變了。

你現在可以在同一個 SQL 查詢裡，利用 PostgreSQL 強悍的 Query Planner，同時做 R-Tree 的地理空間過濾、B-Tree 的時間範圍掃描，最後再加上 HNSW 的向量相似度計算。

資料不需要跨網路移動。Data Locality（資料局部性）完美。

維護分散式事務？不用了，PostgreSQL 的 MVCC 直接幫你搞定。資料一致性從「跨系統的 Eventually Consistent」變回了你最安心的 Strong Consistency。這對工程團隊來說，省下的維運成本是天文數字。

Critique:統一架構的隱患與妥協

當然，說 PostgreSQL 會殺死所有 Vector DB 也不切實際。

HNSW 是出了名的「吃記憶體巨獸」。當你的向量維度高達 1536（比如 OpenAI 的 text-embedding-ada-002），而且資料量來到百億級別，PostgreSQL 的 Shared Buffers 絕對會被撐爆。更別提 Postgres 那個有時讓人抓狂的 Vacuum 機制，在處理頻繁更新的龐大向量索引時，會引發嚴重的 I/O 放大效應。

如果你是 OpenAI、是 Meta，你需要管理千億級別的向量，那你確實需要專門客製化的叢集。

但摸著良心問，台灣有幾家企業的 RAG 向量數會超過一億？

百分之九十九的企業，連一千萬個向量都湊不齊。為了那千萬分之一別人才有的擴展性煩惱，去引入兩三個額外的資料庫組件，這不叫有遠見，這叫 Resume-Driven Development（履歷驅動開發）。

到了 2027 年，隨著硬體記憶體頻寬進一步釋放（比如未來的 DDR6 或更多封裝記憶體），單機 PostgreSQL 輕鬆處置十億級別向量只是基本盤。專屬 Vector DB 要嘛轉型成特定領域的 AI 算力平台，要嘛只能在狹縫中求生。

架構設計的極致，永遠是減法。而我們正在見證一場暴力的化繁為簡。