NL2GQL and Text2Cypher in 2026: The New NL2SQL

Natural language → SQL (NL2SQL) has been a research staple for a decade. In 2026, the graph world is getting its own version — and it is accelerating faster than anything else in the corpus.

Graph Query Languages is the fastest-growing category in the graph-research corpus (+262% year-over-year; 163 papers in the last 12 months). Within that category, NL2GQL — translating natural language into GQL, Cypher, PGQL or SPARQL — is the single largest source of new papers, and it has just acquired what NL2SQL had for years: proper benchmarks.

Why NL2GQL Is the New NL2SQL

The NL2SQL story repeated itself: first benchmarks (Spider), then transfer models, then LLM-based approaches, then agentic orchestration. NL2GQL is at the same point in its lifecycle — except it is arriving with better foundation models than NL2SQL ever had.

Era	NL2SQL	NL2GQL
Benchmarks	Spider (2018)	GQLBench (2026)
Core pain	Dialect variance	Dialect variance × 3 (Cypher, GQL, SPARQL)
Early models	Seq2seq encoders	R³-NL2GQL (2023), MoMQ (2025)
LLM era	Schema-linking + in-context	Alignment fine-tunes, agent frameworks
Agent era	Multi-agent orchestration	NAT-NL2GQL, Multi-Agent GraphRAG Text2Cypher

Two structural facts make graph query generation harder — and more interesting — than NL2SQL:

1. Dialects are more diverse. SQL dialects differ in syntax; graph dialects differ in semantics. Cypher's pattern matching, GQL's path variables, and SPARQL's RDF triples are not equivalent translations — they express different query models.
2. The schema is a graph. Schema linking means choosing which nodes and relationships to traverse, not just which columns to select. A schema that is itself a graph doubles the search space.

The Benchmark Wave: GQLBench and Friends

The field's biggest event in 2026 is the arrival of public benchmarks. GQLBench gives NL2GQL what Spider gave NL2SQL: a large-scale, cross-domain, cross-dialect evaluation set. The research corpus shows three distinct benchmark-driven threads:

• Cross-dialect translation. Adaptive Text2GQL and Aligning LLMs to a Domain-Specific Graph Database for NL2GQL push accuracy on GQLBench by fine-tuning against dialect-specific errors.
• Mixture-of-experts for dialects. MoMQ: Mixture-of-Experts Enhances Multi-Dialect Query Generation attacks the fundamental problem: one model, many dialects. MoE routes different experts to Cypher vs. SPARQL vs. GQL, which outperforms monolithic fine-tuning.
• Multi-agent frameworks. NAT-NL2GQL orchestrates multiple agents (schema analysis, query drafting, verification) instead of a single-pass generation.

The meta-point for practitioners: if you want to evaluate an LLM-powered graph query layer, you no longer have to build the benchmark yourself. GQLBench-style evaluation should be the default starting point for a production Text2Cypher acceptance test.

What the Research Actually Says

1. Alignment beats prompt engineering — but only with the right data

The 2025–2026 alignment papers share one finding: generic LLM instruction-tuning does not produce reliable Cypher/GQL. Alignment against a domain-specific graph database (with real node labels, relationship types, and query patterns) is what moves the needle. This matches what production teams observe: a RAG layer over schema documentation helps, but a fine-tune on actual query logs helps more.

2. Memorisation is a real risk

SPARQL Query Generation with LLMs: Measuring the Impact of Training Data Memorisation (2025) shows that LLMs can memorise training queries and regurgitate them under distribution shift. For graph queries this is worse than for SQL: a memorised query references nodes and properties that may not exist in your database. Verification — executing the query against a schema or a test instance — is not optional.

3. Execution feedback closes the loop

The strongest 2026 systems are iterative: generate → execute against a sandbox → parse errors → retry. Multi-Agent GraphRAG: A Text2Cypher Framework for Labeled Property Graphs and Toward Multi-Database Query Reasoning for Text2Cypher (2026) both converge on execution-grounded refinement. The query generator is no longer a one-shot translation; it is a loop.

Hands-On: A Minimal Text2Cypher Pipeline

A production-ready NL2Cypher layer needs four components: schema context, a translation step, an execution sandbox, and a verification loop.

from neo4j import GraphDatabase
from openai import OpenAI

SCHEMA_PROMPT = """
You are translating natural language into Cypher for a Neo4j graph database.

Schema:
- Node labels: Person, Company, Investment, Product
- Relationships:
  - (Person)-[:FOUNDED]->(Company)
  - (Company)-[:RECEIVED_INVESTMENT]->(Investment)
  - (Company)-[:PRODUCES]->(Product)

Rules:
- Use only node labels and relationship types from the schema above.
- Never invent properties. If a property is ambiguous, ask instead of guessing.
- Return only the Cypher query, no explanation.
"""

def text_to_cypher(question, client, retries=2):
    """Generate Cypher with execution-feedback verification."""
    messages = [
        {"role": "system", "content": SCHEMA_PROMPT},
        {"role": "user", "content": question},
    ]
    for attempt in range(retries):
        query = client.chat.completions.create(
            model="gpt-4o", messages=messages, temperature=0
        ).choices[0].message.content.strip()

        # Verify by parsing — catches malformed Cypher cheaply
        if not is_valid_cypher(query):
            messages.append({"role": "assistant", "content": query})
            messages.append({
                "role": "user",
                "content": "The query above failed to parse. Fix the syntax error and return only the corrected Cypher.",
            })
            continue
        return query
    raise RuntimeError("Failed to generate valid Cypher")

The critical detail is the verification loop: cheap syntactic validation (via the driver's query parser) catches most failures before they reach the database. For semantic validation, add a sandbox read-only transaction that runs the query against a test fixture.

Production Considerations

Concern	Recommendation
Dialect lock-in	Pick one dialect per environment. Cypher for Neo4j, GQL for GQL engines, SPARQL for RDF. Don't build a universal translator first.
Cost	Cache question→query pairs. Fine-tuned small models (7B–32B) beat large-model prompting per-query on cost once volume is significant.
Security	Generated queries must never run with write privileges by default. Read-only roles + query allow-listing + query timeout.
Evaluation	Build a GQLBench-style test set from your own query logs (≥100 curated pairs), and gate deploys on accuracy.
Observability	Log the generated query + the question + execution result for every call. This is your fine-tuning dataset of the future.
Humans in the loop	Show the generated query in the UI ("Query preview") — surprising levels of accuracy gain come from letting users accept/correct.

The Agentic Shift: Query Generation as a Tool Call

The 2026 trajectory is clear: NL2GQL is becoming an agent tool, not a standalone feature. In agentic GraphRAG architectures, the LLM does not just translate a question into a query — it decides whether to query the graph, which pattern to try, and when to retry based on results.

This changes the evaluation story again. Benchmark accuracy on a fixed question→query set stops being the metric; instead you measure task completion (did the agent answer the user's question correctly?) and query efficiency (how many wasted query executions per answer?).

For teams building agents over property graphs, this is the headline: your agent's ceiling is bounded by your NL2GQL accuracy. Every bad query the agent issues is a wasted step; every hallucinated node label is a failed tool call.

The White Space: What Nobody Has Written Yet

The corpus has only 13 review papers in the entire graph-query-languages category — 77% of them in the last 12 months. That means:

• No canonical practitioner survey of NL2GQL tooling exists yet.
• Cross-dialect performance data (not just benchmark accuracy) is scarce — real production accuracy vs. dialect is still mostly anecdotal.
• The convergence of NL2GQL with graph foundation models is essentially unwritten.

These are exactly the gaps a practitioner-oriented site can own: benchmark the tools on real data, report dialect-specific accuracy, and track the agent integration story as it unfolds.

Bottom Line

1. NL2GQL has its Spider moment. GQLBench-style benchmarks make the field evaluable, comparable, and improvable — the same trigger NL2SQL had in 2018.
2. Dialect diversity is the defining problem. MoE and multi-agent architectures exist precisely because one-model-for-all-dialects fails.
3. Execution feedback is mandatory. One-shot generation is legacy; the research consensus is generate → execute → repair.
4. It's becoming an agent primitive. Expect NL2GQL to show up inside agents as a tool call with retry logic, not as a standalone query box.
5. The review white space is open. The fastest-growing graph category in 2026 has almost no practitioner surveys — early coverage builds topical authority.

Evidence base: graph-research corpus — 352 papers in Graph Query Languages, 163 in the last 12 months (+262% YoY), 37 with explicit GQL content. See the GQL deep-dive investigation for the full analysis.

Related Reading

• The GQL Era: Query Languages in 2026 — Where NL2GQL sits in the wider GQL standard wave
• GraphQL vs SPARQL for Knowledge Graphs — Choosing a query layer when natural-language access is the goal
• Neo4j AI: Building Intelligent Applications — The NL-to-Cypher pattern as one of three Neo4j+AI architectures
• Introduction to GraphRAG — Graph queries as the retrieval step inside agentic RAG