Neo4j Virtual Graph is now in public preview
Neo4j's Virtual Graph now provides zero-copy graph querying for Snowflake, Databricks, and BigQuery, targeting GraphRAG and batch exploration workflows.
Deep dive
- Zero-Copy: Data remains in the warehouse; Neo4j provides the graph projection layer.
- Cypher-to-SQL: Deterministic translation layer pushes traversals down to the host database.
- GraphRAG Focus: Designed specifically to provide multi-hop context for agents that struggle with flat tabular data.
- Operational Split: Use Virtual Graph for exploration/RAG, native Neo4j for millisecond-latency transactional graph needs.
- Pricing: Currently free in preview; switching to parity with AuraDB Pro on September 1st.
Decoder
- Cypher: The declarative query language for graph databases, similar to SQL but optimized for pattern matching and traversal.
- GraphRAG: An augmented retrieval method that uses knowledge graphs to provide LLMs with structured, multi-hop context instead of simple vector similarity search.
- Bolt: The proprietary, high-performance protocol used by Neo4j for client-server communication.
Original article
Neo4j Virtual Graph is now in public preview
Earlier this year, we launched Neo4j Virtual Graph in private preview. The response was clear: enterprises want to create knowledge graphs from the data they already have, and they do not want to move data to do so. Today, Virtual Graph moves to public preview, open to every Aura customer, with support for Snowflake, Databricks, and now Google BigQuery. Virtual Graph is built on a flexible foundation designed to extend to additional sources.
Why it matters
Agents are only as good as the context they reason over. GraphRAG outperforms flat retrieval because a knowledge graph captures the relationships that flat retrieval misses; multi-hop questions, such as “which accounts share a beneficial owner?” need a graph to navigate multiple hops out. That set of relationships is what we call a knowledge layer: the context an agent needs to answer a question like that one. Most of that data sits in warehouses and lakehouses that were never built to serve it in graph shape. Copying it out creates pipelines, duplication, and a second system of record susceptible to drift. Virtual Graph removes that trade-off with a zero-copy architecture: your data stays where it is, governed by your existing controls, and you query it as a knowledge graph.
What you get
Connect Virtual Graph to a Snowflake, Databricks, or BigQuery source, and you have a working graph in minutes. Built-in AI tooling proposes a graph model from your tables: which entities become nodes, which keys become relationships (even when foreign keys are not declared), and which columns become properties. You review, adjust, and start querying in Cypher.
Behind the scenes, your Cypher graph query is translated into optimized SQL and pushed down to the source engine. The translation is deterministic, not LLM-driven: the same query produces the same SQL every time, with predictable performance and cost. The heavy lifting runs on compute you already pay for, inside the governance perimeter you already trust, and results come back graph-shaped over Bolt. They are served from a database that looks and behaves like a regular Neo4j database, so all our existing tooling in the platform and client-side can work with it directly.
Three components do the work. The graph data model, optionally generated by AI from your source schema; you own it, and you edit it. The Cypher-to-SQL translation layer, which pushes queries down to the source. And the graph compute layer, which handles the patterns, traversals, and paths that SQL alone cannot express efficiently.
When to use it
Virtual Graph and a graph stored natively in Neo4j solve different problems, and mature graph estates run both.
Reach for Virtual Graph when the data cannot or should not move: too large, too governed, too operational. It suits workloads that tolerate warehouse-grade latency: GraphRAG over reference data, batch enrichment, analyst exploration, and agent workflows that think in seconds. Some estates use a virtual graph as the first step toward a native one; for many, it is the permanent operating mode. Both are valid end states.
Reach for native Neo4j (AuraDB or self-managed) when the workload needs millisecond traversal: real-time decisioning, online fraud scoring, live identity resolution, or continuously updated graphs with ACID writes.
The simple rule: agents that think in seconds fit Virtual Graph. Agents that act in milliseconds want the graph stored natively. And when a hot subset needs both, you will be able to materialize it into native Neo4j without redoing the modeling work.
What is next
Public preview is a step, not the destination. On the roadmap: the ability to materialize a virtual graph into native Neo4j, keeping your model and access setup while unlocking full Cypher, graph algorithms, and native performance on the subsets you choose; federated queries that span an AuraDB graph and a virtual graph in a single Cypher statement; graph algorithm support over virtual graphs; and more sources, including operational databases; and support for self-managed Neo4j deployments.
Get started
Virtual Graph is available today in the Aura Console for Snowflake, Databricks, and Google BigQuery. Connect a source, generate a model, and run your first Cypher query in minutes. Public preview is free to use. We plan to begin billing on September 1st at parity with AuraDB Pro pricing, with general availability to follow shortly after.
Five steps to a first query: connect your Snowflake, Databricks, or BigQuery credentials in the Aura Console; review the AI-proposed graph model and adjust nodes, relationships, and properties; create the virtual graph; connect over Bolt or query directly in the console; explore the results with your existing Neo4j tooling. Watch the demo below. Tell us what you build.
Fresh dev news, AI-digested daily. Never miss a trend at devoured.fyi