PostgreSQL 19: 即將推出的功能與社群期望

PostgreSQL 19 旨在優化開發者體驗並將資料庫的能力擴展到圖形處理與更高效的數據移動。即將發布的版本專注於減少 SQL 查詢中的冗餘代碼，並降低備份與複製的維運開銷。

關鍵功能增強

使用 GROUP BY ALL 簡化查詢語法

PostgreSQL 19 引入了 GROUP BY ALL，這是一個受 DuckDB 啟發的功能，允許使用者在不需顯式列出所有非聚合列的情況下，對所有非聚合列進行分組。這減少了查詢的冗餘度，並在修改複雜報表中的列選擇時，將錯誤降至最低。

圖形資料庫整合

此版本引入了 GRAPH_TABLE 語法，使得在關聯式模型中進行類圖形查詢成為可能。這允許使用者使用類似 Neo4j 的語法在資料表之間進行模式匹配，儘管部分社群成員對此特定實作的冗餘度與效能表示了擔憂。

邏輯複製與 COPY 改進

透過對 COPY 指令與邏輯複製的增強，優化了維運工作流程。這些變更旨在減少數據遷移與備份過程中的開銷，解決了管理大規模部署使用者的常見痛點。

社群技術評論與缺失功能

雖然計劃中的功能受到歡迎，但經驗豐富的 PostgreSQL 使用者已指出目前路線圖中的幾個關鍵缺口：

儲存引擎限制

對於處理日益龐大的數據集，對於原生列式儲存（columnar storage）有強烈需求。使用者指出，雖然存在如 Citus 等擴充功能，但原生支持將減少架構複雜度與依賴風險。

"隨著數據集變得越來越大，PG 的儲存限制正變得越來越顯著。我知道有各種擴充功能... 但接著你就得依賴該擴充功能在未來的支持程度。"

此外，使用者也要求提供原生區塊壓縮（block compression）以取代目前的列級壓縮（row-level compression），後者對於高容量數據往往力不從心。

時序數據與標準合規性

一些開發者正強調缺乏基於 SQL:2011 標準的原生應用程式時間時序數據（application-time temporal data）支持，這將允許更強大的歷史數據追蹤。

維運與架構請求

在目前的專案發展軌跡中，仍有幾項技術需求尚未得到解決：

• 原地升級 (In-place Upgrades): 要求在連續的主要版本之間進行原生原地升級，以消除在容器化 (Docker) 環境中執行 pg_upgrade 的複雜性。
• 連線開銷 (Connection Overhead): 對於每個併發連線的高記憶體佔用仍存有疑慮，這顯示出對更輕量級連線處理的需求。
• 同步物化檢視 (Synchronous Materialized Views): 希望有類似 SQL Server 的 "indexed views"，能夠同步更新以確保在複雜數據場景下的正確性。
• 可插拔儲存引擎 (Pluggable Storage Engines): 對於支援多種儲存引擎（例如 RocksDB）的 MariaDB 式架構感興趣，以針對 OLTP、OLAP 或僅限追加（append-only）的工作負載進行優化。

效能疑慮

儘管增加了新功能，部分使用者對 PostgreSQL 規劃器（planner）的行為仍保持謹慎。具體而言，有報告指出行級安全性 (RLS) 可能導致規劃器預設進行逐行匹配，這會顯著降低生產環境中的效能。