PostgreSQL 19 Beta 3 把 Cypher-like 語法收進 SQL 標準：GRAPH_TABLE 讓多對多查詢不必再開 Neo4j 或裝 Apache AGE

PostgreSQL 19 Beta 3 在 2026 年 8 月 13 日釋出，除了 parallel autovacuum、io_method = worker 自動伸縮、以及 logical replication 開始複製 sequence 這些既定升級外，真正會改變資料模型設計的是 SQL/PGQ——ISO 在 2023 年定稿的圖形查詢標準，正式進入主流開源關聯式資料庫。過往為了處理多對多關係常見的三條路：疊上 recursive CTE、掛 Apache AGE extension、或另外架一套 Neo4j，在 PG19 之後多了一個更貼近原生語意的選項。

SQL/PGQ 這個縮寫背後的標準身世

SQL/PGQ 是 ISO/IEC 9075-16:2023 的一部分，全名 Property Graph Queries。同一批 ISO 委員在 2023 年還推出了 GQL（Graph Query Language），兩者關係像 XQuery 與 XPath：GQL 是獨立語言、SQL/PGQ 是嵌入 SQL 內的圖形模式語法。過去業界圖形查詢語言分裂成 Neo4j 的 Cypher、TinkerPop 的 Gremlin、Oracle 的 PGQL、SPARQL 等各自為政，ISO 這一輪整合等於把 Cypher 的模式匹配風格納入標準體系。

Oracle 23c 在 2023 年就先行實裝過一次，PG19 則是第一個把 SQL/PGQ 帶進廣泛使用的開源關聯式資料庫的版本。這個時間點很關鍵，因為它意味著中小型自架團隊終於能在沒有 Enterprise 授權費、也沒有額外服務要維運的前提下寫圖形查詢。

GRAPH_TABLE 與 CREATE PROPERTY GRAPH 的實際語法

Property graph 在 PG19 裡不是新的儲存結構，而是一層 metadata 映射。既有的關聯資料表被宣告成 vertex table 或 edge table，就能被 GRAPH_TABLE 子句以圖形模式查詢。以最常見的電商模型為例：

CREATE PROPERTY GRAPH myshop
    VERTEX TABLES (
        customers LABEL Customer,
        orders    LABEL "Order",
        products  LABEL Product
    )
    EDGE TABLES (
        customer_orders
            SOURCE customers DESTINATION orders LABEL PLACED,
        order_items
            SOURCE orders DESTINATION products LABEL CONTAINS
    );

當來源與目的表已經有 primary key 與 foreign key 時，PG19 會自動推斷連接欄位；需要顯式標註時可以加 SOURCE KEY (...) REFERENCES ... 語句。實際查詢則長這樣：

SELECT customer_name, product_name
FROM GRAPH_TABLE (myshop
    MATCH (c:Customer)-[:PLACED]->(o:"Order")-[:CONTAINS]->(p:Product)
    WHERE o.ordered_at >= current_date - interval '7 day'
    COLUMNS (c.name AS customer_name, p.name AS product_name)
);

熟悉 Cypher 的人幾乎不用重新學語法；只是節點外面包了一層 GRAPH_TABLE(... MATCH ... COLUMNS ...)，讓整段模式能被當成關聯式運算元嵌回 SELECT、JOIN、CTE 甚至視圖裡。

內部其實還是 JOIN：重寫器架構才是關鍵設計

SQL/PGQ 在 PG19 的實作走的是重寫器路線，不是另開一套 graph storage。planner 在解析階段就把 MATCH 模式展開成一棵傳統的 JOIN 樹，之後所有優化與執行都交回既有機制。這個決策帶來三個直接影響。

第一，既有 index 完全沿用。edge table 的 foreign key 上放的 B-tree、覆蓋索引、部分索引，在圖形模式底下照常被 planner 挑選。這也意味著誤以為「換上圖形語法效能就自動提升」的人會踩雷——底層 index 設計沒動，就不會變快。

第二，維運工具鏈不變。備份、監控、connection pooler、logical replication、pg_stat_statements 的統計，全都繼續適用。相較之下，Apache AGE 會另外建立 ag_catalog schema 存 vertex 與 edge，需要專屬的維運認知；Neo4j 更是徹底獨立的資料庫程序。

第三，深度換效能不會有魔法。Neo4j 之所以在深層遍歷佔優，是因為 index-free adjacency 每一跳都是 O(degree)；PG19 的 SQL/PGQ 每加一跳就是多一次 JOIN，成本至少是 O(log n) 的 index 查找。淺層 pattern 差距不大，一旦跳數上去差距就會被放大。

目前唯一但很關鍵的限制：只支援定深度

PG19 Beta 3 的 GRAPH_TABLE 只實作 fixed-depth pattern。這代表下面這種 Cypher 使用者最常寫的變長路徑模式，PG19 還無法解析：

1 2	-- PG19 尚未支援 MATCH (a:Person)-[:KNOWS*1..5]->(b:Person)

對「找出所有間接下游」「追溯零件供應鏈六層」「社交網路 friend-of-friend-of-friend」這類典型深度未知的圖遍歷，短期內仍需 recursive CTE 或 Apache AGE。官方 roadmap 已明確把 variable-length path 列入後續版本，但沒有給出到齊的版本號。

換言之，SQL/PGQ 在 PG19 這一輪的甜蜜點是結構已知深度的查詢：三跳的訂單分析、二跳的權限展開、固定深度的分類樹遍歷。這些場景過去用 JOIN 也能寫，只是可讀性差。

到底要不要放棄 Neo4j 或 Apache AGE

對正在選型的團隊，建議可以按以下三種情境判斷。

新專案且深度可預期在三跳內：直接等 PG19 GA（PostgreSQL 官方慣例上 Beta 3 之後約兩到三個月進入 RC，再一個月 GA，估計落在 2026 年第四季）。少一個服務要維運、備份策略統一、observability 統一，這些工程收益遠比語法糖重要。

已經在跑 PostgreSQL 17 或 18、暫時不想升 major：Apache AGE 是折衷，代價是接受 ag_catalog 這層獨立儲存與較慢的社群更新節奏。若圖形查詢不是主力工作負載，這一路實務上會比升 PG19 Beta 更保守。

遍歷深度未知、圖形操作是產品核心：Neo4j 仍是量級差距的存在，SQL/PGQ 短期內取代不了。Enterprise 授權昂貴的人可以看 Memgraph 或 KùzuDB 作為替代，但不要指望 PG19 這一輪能解決這個層級的問題。

只是偶爾需要多對多分析：留在 recursive CTE 或視圖也可以，等 PG19 GA 再逐步替換寫法。SQL/PGQ 不是必須立刻導入的東西。

自架 VPS 上該不該提前跑 Beta

Beta 3 依 PostgreSQL 社群一貫立場，不建議正式服務使用，但值得在測試環境開一台 PG19 Beta 3 的 replica 觀察行為。做法上有兩條路。

一是用官方 Docker image：docker pull postgres:19beta3 已可用，搭配 Docker Compose 掛出資料卷後即可跑起來。建議把現有多對多關係表以 CREATE PROPERTY GRAPH 包裝一層，然後用 EXPLAIN (ANALYZE, BUFFERS) 觀察 planner 展開出的 JOIN 順序，藉此驗證既有 index 是否還被有效使用。

二是走 logical replication 建立跨版本 replica。PG19 這一輪剛好強化了這條路徑，wal_level = replica 也能開 logical replication，不必再切成 logical 重啟服務。這讓「把生產資料鏡到一台 Beta VPS 做壓測」的成本比以前低很多。

無論走哪條路，在 GA 之前都要記得 pg_dump 邏輯備份的 SQL/PGQ 語法支援仍在收斂，跨版本 restore 若出錯，優先檢查 property graph 的 DDL 匯出是否被完整保留。

值得注意的一個副作用

SQL/PGQ 進標準之後，實務上會出現一個組織性問題：DBA、後端工程師、資料分析師三方對「多對多查詢該怎麼寫」的共識會被重新洗牌。過去這條界線靠工具切開——分析師寫 SQL、後端寫 ORM、圖形交給 Neo4j 那邊的人；SQL/PGQ 把它們塞回同一段 SQL，程式碼審查與效能瓶頸的責任邊界會需要重新定義。這不是技術問題，卻是導入前值得先在團隊內對齊的事。

該把哪個判斷帶回去

PostgreSQL 19 的 SQL/PGQ 不是「PG 終於能取代 Neo4j」，而是「三跳以內的圖形模式，語法可以寫得像 Cypher，維運卻不多一個服務」。對已經以 PostgreSQL 為主資料庫的自架團隊，這是純粹的減法——少一個 daemon、少一組備份腳本、少一份監控儀表板。真正需要深層變長路徑遍歷的少數場景，該用 Neo4j 就繼續用，兩者不衝突。

自架 PostgreSQL 19 需要一台穩定、I/O 效能夠的機器，尤其在啟用 io_method = worker 與 parallel autovacuum 後，NVMe SSD 帶來的差距會直接反映在 vacuum 時間與圖形 JOIN 展開的 buffer hit rate 上。NCSE Network 的 VPS 位於臺灣是方電訊機房，全機採 Intel Gold CPU 與 NVMe SSD，適合部署對延遲敏感的 PostgreSQL 主從架構；若對海外流量有考量，也可以搭配 IP Transit 服務規劃跨區資料庫複製鏈路。詳細規格可以到 ncse.tw 參考。