SQL:2023 standardized property graph queries; vector search is still vendor-specific in 2026. Use this cheat sheet to compare syntax fast. Read now.
What SQL:2023 fixed for graphs—and what it left open
SQL:2023 standardized property graph queries, so you no longer need a separate graph language just to express nodes, edges, and path patterns inside a relational engine. The core idea is simple: treat your data as vertices and relationships, then pattern-match those relationships in the same SQL session you already use for joins and filters. That matters when the same application needs both tabular reporting and multi-hop navigation—shared schemas, shared transactions, and one query planner instead of two stacks to keep in sync.
Standardization does not mean every engine implements every graph feature the same way. Expect differences in which path patterns are supported, how labels and properties map to tables or columns, and how recursion or variable-length paths are bounded. Use the standard as your baseline vocabulary, then check your vendor’s docs for the subset they actually ship. Write portable patterns first; add engine-specific extensions only where the standard path is missing or too slow for your workload.
Vector search in 2026: still outside the common SQL core
Vector search is still vendor-specific in 2026. Embeddings, distance functions, index types, and the shape of a “find nearest neighbors” clause differ across products. One system may expose a dedicated operator and index type; another may fold similarity into a function call over a special column type. There is no single portable syntax you can paste between engines and trust to plan well.
Treat vector predicates as an extension layer on top of SQL, not as part of the shared graph story. Keep embedding generation, dimension size, and distance metric (cosine, Euclidean, or another) as application-level contracts. In SQL, isolate the nearest-neighbor step so you can rewrite it per vendor without rewriting the rest of the query—filters, joins, aggregations, and authorization stay in ordinary SQL that travels better.
Cheat sheet: side-by-side syntax comparison
When you compare graph and vector syntax fast, line up three columns in your notes: intent, standard or common SQL form, and vendor form. For graphs, intents usually include “match a path,” “filter by node/edge property,” and “project path or neighbor sets.” For vectors, intents usually include “store an embedding,” “rank by similarity,” and “limit to top-k under optional filters.” Mapping intent first stops you from comparing surface keywords that look similar but mean different things.
- Graph path match — Standard property-graph pattern vs. recursive CTE or proprietary path syntax.
- Property filter — Label/property predicates on nodes and edges vs. column predicates on junction tables.
- Vector store — Typed embedding column and any required cast or dimension check.
- Similarity rank — Distance or score expression, ORDER BY, and LIMIT/top-k (or equivalent).
- Hybrid filter — Pre-filter with relational predicates before similarity, or post-filter after; note which order the engine allows.
Fill each row with the shortest working snippet from your engine, not a full query. Keep one reference row for “pure relational equivalent” when a graph pattern can be rewritten as joins—that row is your escape hatch when a feature is missing or a plan goes wrong.
How to use this sheet day to day
Start from the business question: multi-hop relationship, nearest neighbor, or both. If the question is mostly relational with occasional paths, prefer standard graph patterns where available and fall back to joins. If the question is mostly similarity, write the relational filters first, then plug in the vendor’s vector clause last so cardinality and security rules stay clear. When you need both—e.g., similar items only among entities connected by a path—compose in stages: path set or candidate key set, then vector rank over that subset, unless your engine documents a safe combined plan.
Version the cheat sheet with your engine name and build, not only “SQL:2023” or “2026.” Graph support tracks the standard more closely; vector syntax will keep drifting until a shared core exists. Revisit the vector rows whenever you upgrade; leave the graph rows alone unless the vendor documents a new standard feature or a breaking change. The value of the sheet is speed of comparison under pressure—not completeness of every optional clause.