PostgreSQL 不僅僅是一個簡單的關聯式資料庫；它是一個資料管理框架，有可能吞沒整個資料庫領域。
“一切皆用 Postgres”的趨勢不再侷限於少數精英團隊，而是正在成為主流最佳實踐。
OLAP 的新挑戰者
PostgreSQL 生態系統中的一個重大差距是缺乏適用於 OLAP 工作負載的足夠好的列式儲存引擎。雖然 PostgreSQL 本身提供了大量的分析功能，但其對較大資料集進行全面分析的效能並不能完全達到專用的實時資料倉儲的水平。
考慮ClickBench，一個分析效能基準，我們在其中記錄了 PostgreSQL、其生態系統擴充套件和衍生資料庫的效能。未調優的 PostgreSQL 效能較差 ( x1050 )，但透過最佳化可以達到 ( x47 )。此外，還有三個與分析相關的擴充套件：列式儲存Hydra ( x42 )、時間序列TimescaleDB ( x103 ) 和分散式Citus ( x262 )。
這種效能並不算差，特別是與 MySQL 和 MariaDB（x3065、x19700）等純 OLTP 資料庫相比；然而，它的第三層效能還不夠“好”，落後於 Umbra、ClickHouse、Databend、SelectDB（x3~x4）等第一層 OLAP 元件一個數量級。這是一個棘手的地方——使用起來不夠令人滿意，但又太好了而無法丟棄。
然而， ParadeDB和DuckDB的到來改變了遊戲規則！
- ParadeDB的原生 PG 擴充套件pg_analytics實現了第二層效能 ( x10 )，將與頂層的差距縮小到僅 3-4 倍。考慮到額外的好處，這種水平的效能差異通常是可以接受的——無需 ETL 的 ACID、新鮮度和實時資料，無需額外的學習曲線，無需維護單獨的服務，更不用說其 ElasticSearch 級全文搜尋功能。
- DuckDB專注於純粹的 OLAP，將分析效能推向極致（x3.2）——排除專注於學術的閉源資料庫 Umbra，DuckDB 可以說是實用 OLAP 效能最快的。它不是 PG 擴充套件，但 PostgreSQL 可以透過DuckDB FDW和pg_quack等專案充分利用 DuckDB 作為嵌入式檔案資料庫的分析效能提升。
ParadeDB和DuckDB的出現，將PostgreSQL的分析能力推向了OLAP的頂級，填補了其分析效能的最後一個關鍵空白。
OLTP 和 OLAP 之間選擇之難
OLTP 和 OLAP 之間的區別在資料庫誕生之初並不存在。由於傳統 OLTP 資料庫難以支援分析場景的查詢模式和效能需求，OLAP 資料倉儲與資料庫的分離出現於 20 世紀 90 年代。
長期以來，資料處理的最佳實踐涉及使用 MySQL/PostgreSQL 處理 OLTP 工作負載，並透過 ETL 流程將資料同步到專門的 OLAP 系統，如 Greenplum、ClickHouse、Doris、Snowflake 等。
與許多“專業資料庫”一樣，專用 OLAP 系統的優勢通常在於效能——比原生 PG 或 MySQL 實現 1-3 個數量級的提升。然而，代價是冗餘資料、過多的資料移動、分散式元件之間的資料值缺乏一致、專業技能的額外勞動力費用、額外的許可成本、有限的查詢語言能力、可程式設計性和可擴充套件性、有限的工具整合、較差的資料完整性。與完整的 DMBS 相比的可用性。
然而，俗話說“善有善報，惡有惡報”。隨著硬體遵循摩爾定律三十多年來不斷改進，效能呈指數級增長，而成本卻直線下降。 2024年，單臺x86機器可以擁有數百個核心（512 vCPU EPYC 9754 x2），數TB RAM，單個NVMe SSD可以容納高達64TB，單個全快閃記憶體機架可以達到2PB；像 S3 這樣的物件儲存提供了幾乎無限的儲存空間。
硬體的進步解決了資料量和效能問題，而資料庫軟體的開發（PostgreSQL、ParadeDB、DuckDB）則解決了訪問方法的挑戰。這使得分析行業（即所謂的“大資料”行業）的基本假設受到審視。
大資料已死
正如 DuckDB 的宣言“大資料已死”所暗示的那樣，大資料時代已經結束。大多數人沒有那麼多資料，而且大多數資料很少被查詢。隨著硬體和軟體的發展，大資料的前沿正在消退，99%的場景都不再需要“大資料”。
如果現在可以在具有獨立 DuckDB 或 PostgreSQL（及其副本）的單臺計算機上處理 99% 的用例，那麼使用專用分析元件有何意義？如果每部智慧手機都可以自由地傳送和接收簡訊，那麼尋呼機還有什麼意義呢？ （需要注意的是，北美醫院仍在使用尋呼機，這表明可能只有不到 1% 的場景真正需要“大資料”。）
基本假設的轉變正在引導資料庫世界從多元化階段回到趨同階段，從大爆炸轉向大規模滅絕。在這個過程中，一個統一、多模型、超融合的資料庫新時代將出現，OLTP和OLAP重新統一。但誰將領導這項重新整合資料庫領域的艱鉅任務呢？
PostgreSQL：資料庫世界吞噬者
資料庫領域有很多選項：時間序列、地理空間、文件、搜尋、圖形、向量資料庫、訊息佇列和物件資料庫。 PostgreSQL 在所有這些領域中都體現了它的存在。
一個典型的例子是 PostGIS 擴充套件，它為地理空間資料庫設定了事實上的標準； TimescaleDB 擴充套件尷尬地定位了“通用”時間序列資料庫；向量擴充套件PGVector將專用向量資料庫利基變成了笑點。
這不是第一次了；我們在最古老、最大的子領域再次見證了這一點：OLAP 分析。但 PostgreSQL 的野心並不止於 OLAP；它正在關注整個資料庫世界！
是什麼讓 PostgreSQL 如此強大？
當然，它很先進，但 Oracle 也很先進；它是開源的，MySQL 也是如此。
PostgreSQL的優勢來自於它的先進性和開源性，這使得它能夠與Oracle/MySQL競爭。
但它真正的獨特之處在於其極端的可擴充套件性和蓬勃發展的擴充套件生態系統。
PostgreSQL 不僅僅是一個關聯式資料庫；它還是一個關聯式資料庫。它是一個能夠吞沒整個資料庫星系的資料管理框架。除了開源、先進之外，其核心競爭力還源於可擴充套件性，即基礎設施的可重用性和擴充套件的可組合性。
極致可擴充套件性的魔力
PostgreSQL 允許使用者開發擴充套件，利用資料庫的通用基礎設施以最低的成本提供功能。例如，向量資料庫擴充套件pgvector僅有幾千行程式碼，與 PostgreSQL 的數百萬行程式碼相比，其複雜性可以忽略不計。然而，這種“微不足道”的擴充套件實現了完整的向量資料型別和索引功能，優於許多專用向量資料庫。
為什麼？
因為 pgvector 的建立者不需要擔心資料庫一般的額外複雜性：ACID、恢復、備份和 PITR、高可用性、訪問控制、監控、部署、第三方生態系統工具、客戶端驅動程式等，這些都需要數百萬個幾行程式碼就很好解決了。他們只關注問題的本質複雜性。
例如，ElasticSearch 是在 Lucene 搜尋庫上開發的，而 Rust 生態系統有一個改進的下一代全文搜尋庫Tantivy，作為 Lucene 的替代品。 ParadeDB 只需要包裝並連線到 PostgreSQL 的介面即可提供與 ElasticSearch 相當的搜尋服務。更重要的是，它可以站在PostgreSQL的肩膀上，利用整個PG生態的聯合力量（例如與PG Vector的混合搜尋）與另一個專用資料庫進行“不公平”競爭。
可擴充套件性還帶來了另一個巨大的優勢：擴充套件的可組合性，允許不同的擴充套件一起工作，產生1+1»2的協同效應。例如，TimescaleDB可以與PostGIS結合用於時空資料支援；用於全文搜尋的 BM25 擴充套件可以與 PGVector 擴充套件相結合，提供混合搜尋功能。
此外，分散式擴充套件Citus可以透明地將獨立叢集轉變為水平分割槽的分散式資料庫叢集。該功能可以與其他功能正交組合，使PostGIS成為分散式地理空間資料庫，PGVector成為分散式向量資料庫，ParadeDB成為分散式全文搜尋資料庫等等。
更強大的是擴充套件是獨立發展的，不需要繁瑣的主分支合併和協調。這允許擴充套件——PG的可擴充套件性讓眾多團隊可以並行探索資料庫的可能性，所有擴充套件都是可選的，不會影響核心功能的可靠性。那些成熟、健壯的功能有機會穩定地整合到主分支中。
PostgreSQL 透過極致可擴充套件性的魔力實現了基礎可靠性和敏捷功能，使其成為資料庫世界中的異類，並改變了資料庫格局的遊戲規則。
DB Arena 的遊戲規則改變者
PostgreSQL 的出現改變了資料庫領域的正規化：致力於打造“新資料庫核心”的團隊現在面臨著一項艱鉅的考驗——如何在開源、功能豐富的 Postgres 中脫穎而出。他們獨特的價值主張是什麼？
在出現革命性的硬體突破之前，實用的、新型的通用資料庫核心的出現似乎不太可能。沒有任何一個資料庫可以與 PG 的整體實力相媲美，在其所有擴充套件的支援下，即使是 Oracle，也無法與 PG 的開源和免費王牌相媲美。
PostgreSQL 長期以來一直是 HackerNews 和 StackOverflow 中最受歡迎的資料庫。許多新的開源專案預設將 PostgreSQL 作為主要（如果不是唯一）資料庫選擇。許多新一代公司正在全力以赴地使用 PostgreSQL。
正如“ Radical Simplicity: Just Use Postgres ”所說，“Just Use Postgres”可以實現簡化技術堆疊、減少元件、加速開發、降低風險和新增更多功能。 Postgres 可以替代許多後端技術，包括 MySQL、Kafka、RabbitMQ、ElasticSearch、Mongo 和 Redis，輕鬆為數百萬使用者提供服務。Just Use Postgres不再侷限於少數精英團隊，而是成為主流最佳實踐。
對於絕大多數場景來說，PostgreSQL 已經是一個近乎完美的資料庫核心，這使得核心“瓶頸”的想法變得荒謬。以核心修改為賣點的 PostgreSQL 和 MySQL 的分支基本上不會有任何進展。
這與當今 Linux 作業系統核心的情況類似；儘管 Linux 發行版眾多，但每個人都選擇相同的核心。分叉 Linux 核心被認為會造成不必要的困難，業界對此不以為然。
因此，主要的衝突不再是資料庫核心本身，而是兩個方向——資料庫擴充套件和服務！前者涉及內部可擴充套件性，而後者涉及外部可組合性。就像作業系統生態系統一樣，競爭格局將集中在資料庫發行版上。在資料庫領域，只有那些以擴充套件和服務為中心的發行版才有機會取得最終成功。
核心仍然不冷不熱，MySQL 母公司的分支 MariaDB 已接近退市，而 AWS 則透過在免費核心之上提供服務和擴充套件而獲利，蓬勃發展。投資已流入眾多 PG 生態系統擴充套件和服務發行版：Citus、TimescaleDB、Hydra、PostgresML、ParadeDB、FerretDB、StackGres、Aiven、Neon、Supabase、Tembo、PostgresAI
挑戰與整合
PostgreSQL生態系統中的一個困境是許多擴充套件和工具的獨立發展，缺乏一個統一器來協同它們。例如，Hydra 釋出了自己的包和 Docker 映象，PostgresML 也是如此，每個都發布了帶有自己的擴充套件且僅自己的擴充套件的 PostgreSQL 映象。這些映象和包與AWS RDS等綜合資料庫服務相去甚遠。
擴充套件是 PostgreSQL 的靈魂。沒有自由使用擴充套件的 Postgres 就像做飯沒有鹽一樣，受到巨大的限制。
整合 PostgreSQL 生態系統的優勢，打造類似於資料庫世界Ubuntu的協同力量。
- PostGIS：提供地理空間資料型別和索引，這是 GIS 的事實標準（& pgPointCloud、 pgRouting）。
- TimescaleDB：新增時間序列、連續聚合、分散式、列式儲存和自動壓縮功能。
- PGVector：支援 AI 向量/嵌入和 ivfflat、hnsw 向量索引（以及用於稀疏向量的pg_sparse）。
- Citus：將經典的主從 PG 叢集轉變為水平分割槽的分散式資料庫叢集。
- Hydra：新增列式儲存和分析，可與 ClickHouse 的分析功能相媲美。
- ParadeDB：將全文搜尋和混合檢索提升到 ElasticSearch 級別（以及用於中文標記化的zhparser）。
- Apache AGE：圖形資料庫擴充套件，為 PostgreSQL 新增類似 Neo4J 的 OpenCypher 查詢支援。
- PG GraphQL：向 PostgreSQL 新增原生內建 GraphQL 查詢語言支援。
- DuckDB FDW：允許透過 PostgreSQL（和 DuckDB CLI）直接訪問 DuckDB 強大的嵌入式分析資料庫檔案。
- Supabase：基於 PostgreSQL 的開源 Firebase 替代品，提供完整的應用程式開發儲存解決方案。
- FerretDB：基於 PostgreSQL 的開源 MongoDB 替代方案，與 MongoDB API/驅動程式相容。
- PostgresML：促進經典機器學習演算法，使用 SQL 呼叫、部署和訓練 AI 模型。