導讀：本文與各位聊聊Postgres的未來與它的發展簡史、産品特性。
各位開發者和資料庫管理者，如今PostgreSQL 已經不僅僅是一個單純的關系資料庫；它還是一個資料管理架構，有可能吞沒整個資料庫領域。
“一切皆可用 Postgres”的趨勢不再局限于少數精英研發團隊，而是正在成為主流的最佳實踐。
Postgres發展史
Postgres 的起源始于 Ingres 項目。它最初是在加州大學伯克利分校Michael Stonebraker 的指導下以 Ingres（互動式圖形 RE trieval 系統）的 形式開始的。
這個團隊改變和優化了資料庫課程，還資助了一個關系資料庫項目。
最初使用的語言是 QUEL，還不是标準 SQL。ANSI 在 1986 年正式設定了對 SQL 的偏好，許多關系資料庫項目都朝着這個方向發展。1995 年 Postgres95 釋出時添加了 SQL 支援。
1996 年，當 PostgreSQL 的第一個版本 6.0 釋出，開發小級的工作正式走出了學術界，并且成立了 PostgreSQL 全球開發團隊，這也是目前上司該項目的小組。
如今，在使用可靠的資料庫時，很多事情人們都認為是理所當然的事，實際上都是一點點發展起來的。
2000年，Postgres開始了成長之旅。從那年開始，Postgres 開始使用外鍵和連接配接支援，與其它資料庫等級持平。
2002 年左右有了更多關鍵的基礎部分，主要關注成為可靠的資料庫和 SQL，包括以預寫日志( WAL )、外連接配接、模式以及能夠在現實中可能支援 4億 筆交易等。
此外針對IPv6，Postgres 也很早就開始研究這個問題了。
Postgres 社群中的支柱包括 Tom Lane、Josh Berkus、Bruce Momjian、Hiroshi Inoue 和 Peter Eisentraut。
其中一位說：“參與 Postgres 的每個人都對其前景感到非常滿意。他們認為這裡存在更廣的市場機會。而Oracle 已經是一個整體，是以想象并不容易。但開源資料庫浪潮正開始達到頂峰。”
進入 2000 年代後期，特别是 2005 年前，Postgres 已經可以被視為一個相當可靠的資料庫。憑借更豐富的事務支援、廣泛的 SQL 支援以及 WAL 和 VACUUM 等改進。如果你是它的早期采用者，你會開始信任它來處理生産工作負載。
雖然它是值得信賴的，但在易用性方面仍有一些路要走。此時，我們開始看到具有多個不同主題的功能組合，包括如下：
- 并發索引建立
- 熱備伺服器
- 查詢語言改進
- 所有資料類型 - 數組、UUID、ENUM、XML
- 二階段送出
- 更豐富的使用者角色系統
從系統早期開始，我們看到一群人一直在參與其中，但其他的人們也開始加入并貢獻功能。
2009 年，Postgres 8.4 提供了視窗函數和公共表表達式 (CTE)，有了這些，我個人就再也不會回頭用另外一個資料庫了。
有了 Postgres 作為堅實的基礎，大約在這個時候我們開始看到它在更廣泛的資料生态系統開始印記。
由于堅實的代碼庫以及其寬泛的許可證，許多公司采用了 Postgres 并開始對其進行分叉。
在 2000 年代初期到後期，大多數公司要做的第一件事就是向 Postgres 添加 MPP 支援，以便它可以針對更多以 OLAP 為中心的工作負載。當人們将其與對視窗函數和 CTE 等内容的支援相結合時，就将擁有一些新的、強大的東西，而無需從頭開始建構它。
這種類型的産品可以縮短資料庫成熟所需的時間。許多原來的分叉今天已經不存在了，但有些仍然存在于其他産品中......
- Aster Data → 被 Teradata 收購
- Truviso → 被思科收購
- Netezza → 被 IBM 收購
- Greenplum → 被 EMC 收購
- ParAccel → 從未被收購，但實際上成為了 RedShift
盡管 Postgres 分叉出現了一些分散，但Postgres 仍然繼續做它一直在做的事情——繼續前進。
Postgres 9.0 和 9.1的釋出，也就是在2010年，這是 Postgres 變酷的開始。開始對監聽/通知（資料庫中的釋出-訂閱）和 hstore（鍵/值資料類型）等功能的支援打破陳舊的關系資料庫模式。借助對 pg_upgrade.随着 GIN 和 GiST 索引的出現，人們開始獲得的不僅僅是标準 B 樹索引。
擴充始終是 Postgres 的一部分，但通過內建中的一些重構，它們變得更容易為使用者所用。我們看到了 Postgres 外部資料包裝器的開發，是以可以連接配接不同的 Postgres 資料庫。
不僅僅是舊的無聊的資料類型、列和關系。然而，所有這些都是建立在同一個符合 ACID 的、值得信賴的基礎上的。
如果世界現在還沒有注意到 Postgres，那麼你已經被敲響了警鐘。
随着大資料浪潮開始降溫，但 NoSQL 資料庫（Mongo 和 Couchbase）的興起，很明顯開發人員想要一種不同的方式來處理他們的資料。Postgres 也聽取了意見，但後來卻因為它的 JSON 支援而被欺騙了。在 9.2 中提供 JSON 驗證，但被扔到文本字段中。
事實上，我們還得再等兩年才能在 Postgres 中獲得可靠的 JSON 支援。
但是這些都是成長中的必經之路，不是大問題，随着用于輕松應用程式部署—— Heroku 的興起，Heroku Postgres 成為預設資料庫，從 MySQL 資料庫的共享托管和應用程式的 VPS 到 PaaS 以及更專用的資料庫基礎設施的浪潮正在不斷增長。
後來的 Postgres 9.3 版本很棒，我們有橫向連接配接、可更新的外部表、校驗和等等。在 9.4 中，我們在 JSONB資料類型中得到了更好的 JSON支援。這是磁盤上 JSON 的二進制表示形式，這意味着 GIN 索引可以讓更輕松地為資料建立索引，而無需在非常具體的 JSON 函數上建立索引。
JSONB 是一種當人們第一次聽說它時，令人震驚的資料類型和功能。
Postgres 不僅僅适合需要閃亮功能的應用開發人員。邏輯解碼為未來幾年在 Postgres 中更輕松地捕獲變更資料 ( CDC )奠定了基礎。重新整理物化視圖可以實作更豐富的報告用例。背景從業人員啟用了更多功能和創造性用例，特别是對于擴充來說。
亞馬遜随後在 Re:Invent 上宣布支援 RDS 上的 PostgreSQL。人們記得參加過 Re:Invents 活動房間裡，是唯一一次觀衆起立鼓掌的表演。
2016年，小組釋出了9.5、9.6、10。此時，我們開始達到标題功能寫不全的地步，相反地，我們看到了穩定的性能改進和持續增強現有功能的主題。JSONB 獲得了對内聯更新的支援，并且開始看到更多并行執行支援的出現。但這并不全是小更新，根據人們的需求，這裡可能有你一直渴望的主要功能。一些亮點包括：
- 行級安全性
- 邏輯複制
- 表分區
幾年來，PostgreSQL的進步很大程度上仍然是個人貢獻者的結果。我們還看到一些公司在 EnterpriseDB（專注于 Oracle 相容性）、2ndQuadrant（專注于複制）、Postgres Pro（專注于 JSONB）和 Crunchy Data（專注于安全性和雲原生）等特定領域進行了共同努力。
OLAP 的新挑戰者
曾在 2016 年的一次資料庫管理者聚會中，我認為 PostgreSQL 生态系統中的一個重大差距是缺乏适用于 OLAP 工作負載，并且足夠好用的列式存儲引擎。
雖然 PostgreSQL 本身也提供了大量的分析功能，但其對較大資料集進行全面分析的性能并不能完全達到專用的實時資料倉庫的水準。
我們考慮過ClickBench（https://benchmark.clickhouse.com/），一個分析性能基準，我們在其中記錄了 PostgreSQL、其生态系統擴充和衍生資料庫的性能。
其中：未調優的 PostgreSQL 性能較差 ( x1050 )，但通過優化可以達到 ( x47 )。此外，還有三個與資料分析相關的擴充：列式存儲Hydra ( x42 )、時間序列TimescaleDB ( x103 ) 和分布式Citus ( x262 )。
Clickbench c6a.4xlarge、500gb gp2 結果比較的相對時間
以上的性能并不算差，特别是與 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（位址：https://github.com/alitrack/duckdb_fdw）和pg_quack（位址：https://github.com/hydradatabase/pg_quack）等項目都充分利用 DuckDB 作為嵌入式檔案資料庫的分析性能提升。
ParadeDB和DuckDB的出現，将PostgreSQL的分析能力推向了OLAP的頂級，填補了它在分析性能的最後一個關鍵空白。
資料庫領域的鐘擺
OLTP 和 OLAP 之間的差別在資料庫誕生之初，存在與否。由于傳統 OLTP 資料庫難以支援分析場景的查詢模式和性能需求，OLAP 資料倉庫與資料庫的分離開始出現于 20 世紀 90 年代。
長期以來，資料處理的最佳實踐涉及使用 MySQL/PostgreSQL 處理 OLTP 工作負載，并通過 ETL 流程将資料同步到專門的 OLAP 系統，比如 Greenplum、ClickHouse、Doris、Snowflake 等。
DDIA ch3：OLTP 分析王國
與許多“專業資料庫”一樣，專用 OLAP 系統的優勢通常在于性能— 比本機 PostgreSQL 或 MySQL 提高 1-3 個數量級。
這裡比較的元素，包括從成本，備援資料、過多的資料移動、分布式元件之間的資料缺乏一緻、專業技能的額外勞動力費用、額外的許可成本、有限的查詢語言能力、可程式設計性和可擴充性、有限的工具內建、較差的資料完整性和可用性與完整的DMBS 的次元對比。
随着硬體遵循摩爾定律三十多年來不斷改進，性能呈指數級增長，而成本卻直線下降。到 2024 年，單個 x86 伺服器可以擁有數百個核心（512 個 vCPU、EPYC 9754 x2）、數 TB RAM、單個NVMe SSD 可以容納高達64TB / 3M 4K rand IOPS / 14GB /s，以及單個全閃存架可達數PB；像 S3 這樣的對象存儲提供了幾乎無限的存儲空間。
I/O 與帶寬每 3 年翻一番
硬體的進步解決了資料量與性能問題，而資料庫軟體的開發（PostgreSQL、ParadeDB、DuckDB）則解決了通路方法的挑戰。這使得分析行業（即所謂的“大資料”行業）的基本假設受到審視。
正如 DuckDB 的宣言“大資料已死”所暗示的那樣，大資料時代已經結束。大多數人沒有那麼多資料，而且大多數資料很少被查詢。随着硬體和軟體的發展，大資料的熱潮正在消退，99%的場景都不再需要“大資料”。
如果現在可以在具有獨立 PostgreSQL/DuckDB（及其副本）的單台計算機上處理 99% 的用例，那麼使用專用分析元件還有什麼意義？
如果每部智能手機都可以自由地發送和接收文本，那麼尋呼機還有什麼意義呢？（需要大家注意的是，北美地區醫院仍在使用尋呼機，這表明可能隻有不到 1% 的場景真正需要“大資料”。）
基本假設的轉變正在引導資料庫世界從多元化階段回到趨同階段，從大爆炸轉向大規模滅絕。
在這個過程中，一個統一、多模型、超融合的資料庫新時代即将出現，OLTP和OLAP重新統一。但誰将上司這項重新整合資料庫領域的艱巨任務呢？
PostgreSQL：資料庫世界的吞噬者
資料庫領域有很多技術利基：時間序列、地理空間、文檔、搜尋、圖形、矢量資料庫、消息隊列和對象資料庫。PostgreSQL 在所有這些領域中都展現了它的存在。
一個典型的例子是 PostGIS 擴充，它為地理空間資料庫設定了事實上的标準；TimescaleDB 擴充尴尬地定位了“通用”時間序列資料庫；向量擴充PGVector将專用向量資料庫利基變成了笑點。
這已經不是第一次了；我們在最古老、最大的子領域再次見證了這一點：OLAP 分析。但 PostgreSQL 的野心并不止于 OLAP；它現在正在關注整個資料庫世界！
PostgreSQL 生态系統
是什麼讓 PostgreSQL 如此強大？當然，它很先進，但是 Oracle 也很先進；但它是開源的，MySQL 也是如此。PostgreSQL的優勢來自于它的先進性和開源性，這使得它能夠與Oracle/MySQL競争。
但它真正的獨特之處在于其極端的可擴充性和蓬勃發展的擴充生态系統。
使用者選擇 PostgreSQL 的原因：開源、可靠與可擴充
極緻可擴充性的魔力
PostgreSQL 不僅僅是一個關系資料庫；它是一個能夠吞沒整個資料庫星系的資料管理架構。除了開源、先進之外，其核心競争力還源于可擴充性，即基礎設施的可重用性和擴充的可組合性。
PostgreSQL 允許使用者開發擴充，利用資料庫的通用基礎設施以最低的成本提供功能。例如，矢量資料庫擴充pgvector僅有幾千行代碼，與 PostgreSQL 的數百萬行代碼相比，其複雜性可以忽略不計。
pgvector位址：
https://github.com/pgvector/pgvector
然而，這種“微不足道”的擴充實作了完整的矢量資料類型和索引功能，卻優于許多專用矢量資料庫。
為什麼？因為 pgvector 的建立者不需要擔心資料庫一般的額外複雜性：ACID、恢複、備份和 PITR、高可用性、通路控制、監控、部署、第三方生态系統工具、用戶端驅動程式等，這些都需要數百萬個幾行代碼就很好解決了。他們隻關注問題的本質複雜性。
例如，ElasticSearch 是在 Lucene 搜尋庫上開發的，而 Rust 生态系統有一個改進的下一代全文搜尋庫Tantivy，作為 Lucene 的替代品。
Tantivy位址：
https://github.com/quickwit-oss/tantivy
ParadeDB 隻需要包裝并連接配接到 PostgreSQL 的接口即可提供與 ElasticSearch 相當的搜尋服務。
更為重要的是，它可以站在PostgreSQL的肩膀上，利用整個PG生态系統的聯合力量（例如與pgvector的混合搜尋）與另一個專用資料庫進行“不公平”競争。
請看下圖：
Pigsty & PGDG 有 234 個可用擴充,生态系統中還有1000多個
可擴充性帶來了另一個巨大的優勢：擴充的可組合性，允許不同的擴充一起工作，産生1+1大于2的協同效應。
我們舉個例子，TimescaleDB可以與PostGIS結合用于時空資料支援；用于全文搜尋的 BM25 擴充可以與 PGVector 擴充相結合，提供混合搜尋功能。
此外，分布式擴充Citus可以透明地将獨立叢集轉變為水準分區的分布式資料庫叢集。
Citus位址：
https://www.citusdata.com/
該功能可以與其它産品功能組合，比如使PostGIS成為分布式地理空間資料庫，PGVector成為分布式矢量資料庫，ParadeDB成為分布式全文搜尋資料庫等等。
更強大的是，擴充是獨立發展的，不需要繁瑣的主分支合并和協調。這種技術使得PG的可擴充性讓衆多團隊可以并行探索資料庫的可能性增大，所有擴充都是可選的，不會影響核心功能的可靠性。那些成熟、健壯的功能有機會穩定地內建到主分支中。
PostgreSQL通過極緻可擴充性的“魔力”實作了基礎可靠性和靈活功能，使其成為資料庫世界中的異類，并改變了資料庫格局的遊戲規則。
DB Arena 的遊戲規則改變者
PostgreSQL 的出現改變了資料庫領域的範式：緻力于打造“新資料庫核心”的團隊現在面臨着一項艱巨的考驗：如何在開源、功能豐富的 Postgres 中脫穎而出。
那麼，他們獨特的價值主張是什麼？
在出現革命性的硬體突破之前，實用的、新型的通用資料庫核心的出現似乎不太可能。目前還沒有任何一個單一的資料庫可以與 PG 的整體實力相媲美，在其所有擴充的支援下，即使是 Oracle，也無法與 PG 的開源和免費的王牌相媲美。
如果一個利基資料庫産品能夠在特定方面（這通常是性能）比 PostgreSQL 好一個數量級，那麼它可能會為自己開辟出一席之地。然而，通常用不了多久，PostgreSQL 生态系統就會産生開源擴充替代品。選擇開發 PG 擴充而不是全新的資料庫可以讓球隊在追趕時獲得碾壓性的速度優勢！
按照這個邏輯，PostgreSQL 生态系統将滾雪球一般，不斷積累優勢，并不可避免地走向壟斷，在幾年内反映 Linux 核心在伺服器作業系統中的地位。開發者調查和資料庫趨勢報告中亦證明了這一軌迹。
StackOverflow 2023 年調查：PostgreSQL，十項全能選手
StackOverflow 過去 7 年的資料庫趨勢
PostgreSQL 長期以來一直是 HackerNews 和 StackOverflow 中最受歡迎的資料庫。許多新的開源項目預設将 PostgreSQL 作為主要（如果不是唯一）資料庫選擇。
PostgreSQL 與大多數其他關系資料庫最根本的不同之處之一來自于它的核心設計。
大多數關系資料庫最好被描述為關系資料庫管理系統（RDBMS）。RDBMS 是專門為處理關系資料庫而設計的軟體，其中資料存儲在具有預定義列和資料類型的表狀結構中。可以使用基于關系代數的技術（通常通過結構化查詢語言（SQL））來查詢、修改和檢索資料。
另一方面，PostgreSQL 從技術上來說是一個對象關系資料庫管理系統 (ORDBMS)。這意味着它具有與 RDBMS 相同的關系功能，但還具有一些面向對象的功能。
實際上，這意味着 PostgreSQL 允許你：
- 定義你自己的複雜資料類型
- 重載函數以處理不同的參數資料類型
- 定義表之間的繼承關系
這些功能是強大的工具，可幫助你使用程式設計時可能熟悉的一些相同技術來處理資料庫和資料。增加的靈活性使您可以在資料庫系統内而不是在程式外部對不同類型和關系進行模組化。這可以幫助保持一緻性并強制執行更接近實際資料的預期行為。
PostgreSQL 是一個由PostgreSQL 全球開發小組管理的開源項目。它使用PostgreSQL 許可證進行許可，這是開源促進會認可的許可證。
雖然還有許多其他開源關系資料庫，但 PostgreSQL 是在沒有企業所有者或商業同行的情況下開發和管理的。這有助于貢獻者制定自己的道路并緻力于社群最關心的功能。PostgreSQL 的專業服務由經常為項目做出貢獻但不控制開發過程的公司提供。
這種對社群驅動開發的關注導緻了 PostgreSQL 使用者的大力參與。大量高品質的擴充和應用程式可用于增強核心 PostgreSQL 軟體的功能。社群開發的軟體可以幫助您管理 PostgreSQL 伺服器、編譯商業智能報告、管理新類型的資料以及通過各種程式設計語言和平台使用 PostgreSQL。
而現在，許多新一代公司正在全力以赴地使用 PostgreSQL。
就像“ Radical Simplicity: Just Use Postgres ”所說，“Just Use Postgres”可以實作簡化技術堆棧、減少元件、加速開發、降低風險和添加更多功能。
Postgres 可以替代許多後端技術，包括 MySQL、Kafka、RabbitMQ、ElasticSearch、Mongo 和 Redis，輕松為數百萬使用者提供服務。Just Use Postgres不再局限于少數精英團隊，而是成為主流的最佳技術實踐。
各位，你的選擇将塑造資料庫世界的未來。我希望本文可以幫助你更好地利用世界上最先進的開源資料庫核心：PostgreSQL。
https://medium.com/@fengruohang/postgres-is-eating-the-database-world-157c204dcfc4