SQL-2026 Graph and Vector Querying [2026 Cheat Sheet]

As of April 17, 2026, the practical baseline is not a published “SQL:2026” core release for graph and vector work. What is public and shipping is SQL:2023 Part 16, also called SQL/PGQ, for property graph querying. By contrast, vector types, vector indexes, and similarity functions are still exposed through vendor extensions rather than one cross-engine ISO syntax.

Reality Check

Use this framing to avoid mixing standards with product marketing:

• Standardized now: SQL/PGQ in SQL:2023 for property graphs.
• Adjacent standard: GQL became its own ISO language in 2024.
• Not standardized across engines: vector column types, similarity functions, approximate nearest neighbor indexes, and most hybrid graph-plus-vector syntax.
• Operational implication: write one reference layer for graph traversal and one compatibility layer for vector search.

Live Search Reference

Filter commands by keyword. Keyboard support is built in below.

Commands by Purpose

1. Define a Property Graph

This is the standards-shaped entry point. Engines vary in exact support, but the portable concept is stable.

CREATE PROPERTY GRAPH orggraph
  VERTEX TABLES (
    employees KEY (employeeid),
    departments KEY (departmentid)
  )
  EDGE TABLES (
    reportsto
      SOURCE KEY (employeeid) REFERENCES employees
      DESTINATION KEY (managerid) REFERENCES employees,
    belongsto
      SOURCE KEY (employeeid) REFERENCES employees
      DESTINATION KEY (department_id) REFERENCES departments
  );

Use when: you want relational tables exposed as vertices and edges without moving data into a separate graph store.

2. Match Graph Patterns with GRAPH_TABLE

This is the anchor command to memorize. Think of it as graph pattern matching that returns rows back into SQL.

SELECT q.employeename, q.managername
FROM GRAPHTABLE(
  orggraph
  MATCH (e IS employees) -[r IS reportsto]-> (m IS employees)
  COLUMNS (
    e.name AS employeename,
    m.name AS managername
  )
) AS q
ORDER BY q.managername, q.employee_name;

Use when: you need joins that are easier to express as edges than foreign-key chains.

3. Reachability and Path-Shaped Queries

Path syntax is where graph querying stops looking like ordinary SQL joins and starts paying for itself.

SELECT q.srcname, q.dstname
FROM GRAPHTABLE(
  orggraph
  MATCH (src IS employees) -/:reportsto*/-> (dst IS employees)
  WHERE src.employeeid = 42
  COLUMNS (
    src.name AS srcname,
    dst.name AS dstname
  )
) AS q;

Use when: you need multi-hop traversal, ancestor chains, fraud rings, dependency spread, or recommendation walks.

4. Mix Graph Output Back into Relational SQL

The practical advantage of SQL/PGQ is not graph alone. It is graph inside ordinary analytics pipelines.

WITH reportingedges AS (
  SELECT 
  FROM GRAPHTABLE(
    orggraph
    MATCH (e IS employees) -[r IS reportsto]-> (m IS employees)
    COLUMNS (
      e.employeeid AS employeeid,
      m.employeeid AS managerid
    )
  ) AS gt
)
SELECT d.departmentname, COUNT() AS edgecount
FROM reportingedges re
JOIN employees e ON e.employeeid = re.employeeid
JOIN departments d ON d.departmentid = e.departmentid
GROUP BY d.departmentname
ORDER BY edge_count DESC;

5. Vector Similarity: Vendor-Specific Layer

No single ISO syntax covers vectors across the major engines in April 2026. The safe documentation pattern is to show the shape and label it clearly as engine-specific.

SELECT TOP 10 docid,
       VECTORDISTANCE('cosine', embedding, @query_embedding) AS distance
FROM docs
ORDER BY distance ASC;

Use when: your engine exposes native vector functions. Keep these calls behind repository methods, views, or macros if portability matters.

6. Hybrid Retrieval: Vector First, Graph Second

This is the cleanest 2026 architecture for many AI applications: rank candidates semantically, then traverse relationships.

WITH semanticcandidates AS (
  SELECT docid
  FROM docs
  ORDER BY VECTORDISTANCE('cosine', embedding, @queryembedding) ASC
  FETCH FIRST 50 ROWS ONLY
)
SELECT gt.docid, gt.relateddocid
FROM semanticcandidates sc
JOIN GRAPHTABLE(
  contentgraph
  MATCH (d IS documents) -[r IS cites]-> (d2 IS documents)
  COLUMNS (
    d.docid AS docid,
    d2.docid AS relateddocid
  )
) AS gt
  ON gt.docid = sc.doc_id;

Rule of thumb: vector search narrows the search space; graph traversal explains or expands it.

7. Hybrid Retrieval: Graph First, Vector Second

Reverse the order when the relationship boundary is the hard constraint, such as tenant, lineage, or policy scope.

WITH graphscope AS (
  SELECT gt.docid
  FROM GRAPHTABLE(
    contentgraph
    MATCH (u IS users) -[r IS canaccess]-> (d IS documents)
    WHERE u.userid = @userid
    COLUMNS (d.docid AS docid)
  ) AS gt
)
SELECT d.docid,
       VECTORDISTANCE('cosine', d.embedding, @queryembedding) AS distance
FROM docs d
JOIN graphscope gs ON gs.docid = d.doc_id
ORDER BY distance ASC
FETCH FIRST 10 ROWS ONLY;

Keyboard Shortcuts

The helper script in this reference supports these shortcuts:

Configuration

Most teams fail here by assuming the presence of graph and vector features implies one coherent standard surface. In practice, you need a feature matrix.

• Graph capability: does the engine expose CREATE PROPERTY GRAPH, GRAPH_TABLE, path matching, and graph metadata?
• Vector capability: does the engine expose a native vector type, an array-backed convention, or an extension module?
• Index strategy: exact scan only, exact plus B-tree helpers, or ANN structures such as HNSW-like implementations?
• Optimizer behavior: can relational predicates push down around graph and vector operators?
• Governance: can you mask embeddings, path outputs, and entity identifiers before export?

capabilities:
  graphsqlpgq: true
  graphpathpatterns: true
  graphshortestpath: vendorcheck
  vectortype: vendorcheck
  vectordistancefn: vendorcheck
  vectorannindex: vendorcheck
  hybridpushdown: benchmark_required

Documentation pattern: keep one standards section, one vendor notes section, and one benchmark section. Do not merge them.

Advanced Usage

Design for two portability bands

• Band 1: graph definitions and graph pattern queries written as close as possible to SQL/PGQ.
• Band 2: vector storage, indexing, and distance functions wrapped behind stable application interfaces.

Benchmark hybrid plans, not isolated operators

A fast vector primitive does not guarantee a fast pipeline. Measure the whole retrieval path: vector candidate generation, graph expansion, relational filtering, and final sort.

Prefer explicit security boundaries

Embeddings can leak information through nearest-neighbor behavior. Mask examples in docs, redact identifiers in shared notebooks, and avoid shipping raw production vectors into demo data sets.

Use graph for explainability

When a semantic result matters to users, graph context often supplies the explanation layer: who linked to it, what cited it, what depends on it, and what policy allows it.

Keep syntax notes brutally clear

• Label standard commands as standard.
• Label engine-specific vector examples as engine-specific.
• Never imply that one vendor's vector function name is portable SQL.

Sources

These are the primary references behind the portability claims in this sheet:

• Oracle: SQL/PGQ is Part 16 of SQL:2023
• Google Cloud Spanner: relationship between SQL/PGQ and GQL
• GQL standard community reference for ISO/IEC 39075:2024
• Microsoft Learn: vendor vector search and vector indexes in SQL Server
• DuckPGQ: open documentation for SQL/PGQ syntax and examples