Graph Query Language(GQL，圖形查詢語言) 是由同時維護 SQL 標準的國際工作組開發和維護的一種新語言。
GQL 很大程度上借鑑了現有的語言，主要的靈感來自 Cypher(現在實現版本有 10 多個，包括 6 個商業產品)、Oracle 的 PGQL 和 SQL 本身。GQL 項目是自 SQL 之後的第一個 ISO/IEC 國際標準數據庫語言項目。
今年 6 月，隸屬 ISO/IEC 聯合技術委員會 1(負責定製 IT 標準)的全球諸多國家性標準機構開始就 GQL 項目提案進行表決，有七個國家派出專家參與這項爲期四年的項目。在本週投票結束，提案獲得通過。
共有十個國家投出了贊成票，其中包括中國、韓國、瑞典、美國、德國、英國、荷蘭、丹麥、哈薩克斯坦、加拿大和芬蘭。另外有五個國家選擇棄權，其理由是缺乏對該提案作出判斷或發表評論的專門知識。
只有日本投了反對票，它列舉了兩個理由：
- 現有的語言已經能實現這類需求
- 具體來說，SQL/Property Graph Query 擴展以及 SQL 標準的其餘部分可以滿足需求
爲什麼我們需要一種特定於圖形的查詢語言？
許多供應商、研究人員和用戶一致認爲，可以使用非關係型“圖形原生”存儲和運行時模型來開發圖形數據庫。例如 Neo4j 的行業領先的圖形數據庫平臺和新的 Redis Labs 圖形產品。
但是，他們也需要一種類似 Cypher 的語言來支持數據的插入和維護，而不僅僅是數據查詢。對於以圖行爲中心的語言來說，SQL 不太可能是一個合適的模型，所需的語言是能夠將圖形作爲查詢輸入，然後輸出一個圖，就像 SQL 可以讀取表，並生成實爲新表的結果集。
GQL 和 SQL 如何協同工作？
許多支持 GQL 提案的公司和國家標準機構並不認爲 GQL 和 SQL 是競爭對手，而是通過共享的基礎和互操作來相互補充。(其中指的是核心數據類型和表達式的形成方式，以及共享的概念，如目錄中持有的模式對象，以及與用戶/角色相關的會話)。
SQL/PgQ 查詢實際上是一個圍繞着一段“proto-gql”的 SQL 子查詢。下面有一個示例查詢，在今年 SIGMOD 大會接近尾聲時，Oracle 的Oskarvanrest 爲今年 7 月在阿姆斯特丹舉行的鏈接數據庫基準理事會(Link Database Benchmark Council，LDBC)會議提出的。
以關鍵字 MATCH 開頭的紅色部分是模式匹配查詢的一個片段，該查詢非常類似用 Cypher 或 PGQL 編寫的查詢。你可能會注意到，它用於引入標籤(如在 Creator IS Person 中)，以及用於引入主機參數或變量。但是，你也可以在標籤表達式中使用冒號(如果 SQL 引擎的解析器是智能的)，那麼與先前存在的“輸入”屬性圖查詢語言的相似性就會更加明顯。
PgQ 查詢的其他部分(黑色和綠色)將這個 Proto-GQL 連接到一個 SQL SELECT 語句中。表格結果通過 Columns 子句流到常規 SQL 查詢中。它們只對與圖形查詢交互的 SQL 引擎來說是需要注意的，GQL 本身不會涉及到這種 SQL“外部函數接口”。
SQL 生成表，GQL 生成圖
SQL 在一個關鍵方面與 Cypher 語言大不相同，Cypher 讓用戶在不知道將返回哪些類型的數據的情況下探索其數據圖的結構。它可以讓你進行真正的圖形查詢，其中值得注意不僅僅是值，還包括數據子集的形狀，與匹配圖模式的元素的值有關。換句話說，圖查詢針對在一個或多個輸入圖上計算的子圖或投射圖。
然而，SQL/PGQ、Cypher 和 PGQL 只允許你從圖中提取一個表。這是必須保留的重要特性，因爲否則就不可能獲取存儲在圖元素上的實際數據值。但是將結果僅限於表意味着你無法輕鬆創建圖轉換鏈，也無法針對多個輸入圖執行集合操作。你也無法生成和存儲快照圖，無法定義圖投射視圖。
GQL 將建立在 openCypher Morpheus 的基礎上(它將 Cypher 引入到 Apache Spark)，並結合來自 LDBC 的 G-CORE 的靈感，爲用戶提供了一種組合圖查詢語言，支持所有那些功能，這將使 GQL 在概念上等同於 SQL。
更普遍地說，GQL 是一種比 SQL 更現代的語言，它具有更結構化的類型系統。
GQL 項目的工作將於本月晚些時候在坦桑尼亞阿魯沙召開的 SQL/GQL 標準委員會 ISO/IEC JTC 1 SC 32/WG3 的下一次會議上全面開始。
目前還無法確定 GQL 的第一個可實現版本，但很有可能在 2020 年下半年之前制定某個相當完整的草案。