cloudparts

Graph lakehouses

Query lakehouse tables as a graph, with Cypher, Gremlin or GQL, without copying the data into a separate graph database.

1 technology on this page ↓

How it works

The data stays where it is: tables in Iceberg, Delta Lake or Hudi, registered in a catalog and already used by SQL engines and notebooks. On top you declare a graph model, which is only a mapping: this table holds User nodes keyed by its primary key, these columns are their properties, this foreign key or join table is a MEMBER_OF edge. A graph engine then takes a query such as MATCH (u:User)-[:MEMBER_OF*1..3]->(g:Group), plans it as node and edge operators, reads only the columns it needs with filters pushed down to storage, skips files using the table format’s statistics, and does the traversal in its own memory. Permissions come from the catalog, so a graph query sees what the same user could read with SQL. Products differ in how much they copy. PuppyGraph runs its own distributed engine and sends only simple projection and filter SQL to the source. Neo4j’s Virtual Graph (private preview in 2026) translates Cypher into SQL that runs on Databricks or Snowflake. BigQuery Graph defines node and edge tables over existing tables and queries them with GQL. Microsoft Fabric’s graph maps OneLake tables to nodes and edges but ingests them into graph storage on save and on a refresh schedule, and TigerGraph loads lakehouse tables through Spark or Kafka Connect, so those keep a managed copy. A 2026 research engine, GraphLake, loads only the key columns that form the topology (about 3% of the data in its benchmark) and fetches properties on demand. The trade-off is the storage layout: Parquet files are built for scans, so following a few edges at a time is slower than in a database that stores each node’s neighbours together.

Think of it as

Tracing routes on a transparent sheet laid over the official city map. You draw only the lines you care about, but the map underneath stays the single copy, and it is always the current edition.

Reach for it when

  • The data already lives in lakehouse tables and the questions follow links of unknown depth: fraud rings, attack paths and nested group access, supply-chain dependencies, data lineage
  • Analytical traversals over large data, where a second copy and the pipeline that keeps it in sync would cost more than the queries
  • You want one set of permissions, retention and lineage rules: graph queries go through the same catalog as SQL
  • You are still finding out which relationships matter, and want to change the model by editing a mapping rather than re-ingesting

Think twice when

  • An application needs low-latency lookups of a few hops, or writes many small changes to the graph: a graph database that stores adjacency directly does this better
  • The questions are aggregates over a few well-known joins; SQL on the same tables already answers them
  • Keys don’t line up across tables: edges are only as good as the keys, so entity resolution has to come first
  • A few nodes have millions of edges and every query touches them; one hop through such a node can explode in size

A real example

A security team keeps identities, group memberships and login events as Iceberg tables. They map users, groups and hosts to node types and memberships and logins to edge types, and an analyst asks in one openCypher query which users can reach a domain controller through up to three nested groups. The engine reads the same tables the SQL dashboards use, so there is no nightly copy into a graph database and the answer reflects the latest committed snapshot.

Technologies

Specific products, and what each does differently.

What each provider calls it

AWS
No in-place graph engine for lakehouse tables: Neptune Analytics loads CSV or Parquet from S3 into memory, which is a copy. PuppyGraph runs on AWS and reads Iceberg tables in S3 Tables
Google Cloud
BigQuery Graph: node and edge tables defined over existing tables or views and queried with GQL, without replicating data (needs Enterprise or Enterprise Plus)
Azure
Graph in Microsoft Fabric: a GQL graph modelled over OneLake lakehouse tables, ingested into graph storage when the model is saved and on a refresh schedule
Open source & others
Mostly commercial so far: PuppyGraph (free single-node Developer Edition), Neo4j Virtual Graph (private preview, over Databricks and Snowflake); research: GraphLake from TigerGraph and Purdue

Worth exploring

Article· June 2026Graph and Lakehouse, Friends at LastEric Monk, Neo4jA hands-on walkthrough of Neo4j’s Virtual Graph, then in private preview: a graph model laid over Databricks tables (TPC-H in the example) without copying them, where Cypher is translated deterministically into SQL that runs on Databricks compute under Unity Catalog permissions, and EXPLAIN shows the generated SQL. Useful for its worked queries and its honest list of current limits (single-column node IDs, unique relationship types, memory limits on big aggregations); it is a Neo4j post about a Neo4j product and has no performance numbers.
Paper· March 2026GraphLake: A Purpose-Built Graph Compute Engine for LakehouseShige Liu, Songting Chen, Chengjie Qin, Mingxi Wu and Jianguo Wang (Purdue University, TigerGraph), arXivExplains why running graph analytics over Iceberg tables is hard and how a TigerGraph-based engine does it: load only the key columns that form the topology, build one edge list per Parquet file, encode file and row in each vertex ID so properties can be fetched on demand, and cache column chunks with graph-aware priorities. On LDBC benchmarks it reports up to 26× faster startup and up to 60× faster queries than PuppyGraph, and it is candid that edge-list scans lose to TigerGraph’s own storage when few edges match. Half the authors work at TigerGraph and the baseline is a closed-source competitor measured from outside, so read the comparison with that in mind.
Video· January 2026Unified Data, Unified Insights: Meet the Graph LakehouseWeimo Liu and Jaz Ku (PuppyGraph) and Robert Pack (Databricks), Open Lakehouse + AIA 50-minute live session from the Delta Lake community with demos of querying Delta Lake tables as a graph with PuppyGraph, running multi-hop Cypher and Gremlin queries, and visualising the results, without a separate graph database or copy pipeline. Summarised here from the event description and listing; two of the three speakers are from PuppyGraph.
Video· February 2023Graph Queries on Data LakesWeimo Liu (PuppyGraph), Trino communityAn early talk for the Trino community making the case for a graph data lake instead of a graph database: keep the data once in tables such as Iceberg, start a separate graph query engine when you need traversals, and shut it down afterwards without losing anything. Summarised here from the event description; the speaker is PuppyGraph’s CEO, and the talk predates its product launch.
All resources →

Often confused with

LakehousesQuery enginesTable formatsLakehouse catalogs
Where it came from2023–2026

For years, graph analysis meant a second system. Teams kept their data in a warehouse or lake and ran ETL jobs to copy it into Neo4j, TigerGraph or Neptune, then kept the two in sync. In a February 2023 talk for the Trino community, PuppyGraph’s Weimo Liu argued that many users want a graph data lake instead: start a graph engine against Iceberg tables, run the query, turn the engine off, and keep a single copy of the data. PuppyGraph launched on that idea in March 2024.

Standards helped. SQL:2023 added SQL/PGQ for graph patterns over relational tables, and ISO published GQL in April 2024. Cloud platforms followed with graph layers over their own tables: BigQuery Graph queries existing tables with GQL, and Microsoft Fabric added graph over OneLake data, although it loads that data into its own graph storage.

By 2026 the graph database vendors had joined in. In January a Delta Lake community session demonstrated querying Delta tables as a graph with PuppyGraph; in March, TigerGraph and Purdue researchers published GraphLake, an engine that queries Iceberg tables in place and reports large speedups over PuppyGraph; and in June Neo4j described Virtual Graph, which translates Cypher into SQL on Databricks under Unity Catalog permissions. PuppyGraph notes that the term is not standardised: some vendors use it for systems that copy data, others only for querying tables in place.

Why it’s built this way

The graph is a mapping, not a copy
A second copy brings drift, an ETL pipeline and a second permission system. Declaring nodes and edges over existing tables keeps one system of record and one governance perimeter.
Push filters and projections down, traverse in the engine
Columnar files are good at reading a few columns of many rows, not at random access, so engines read only the needed columns and do the hop-by-hop work in their own memory.
Load the topology, fetch properties on demand
The GraphLake paper found the key columns that define nodes and edges are about 3% of the data, so loading only those gives fast startup while the rest stays in the lake.
Translate to SQL, or run a separate engine
Neo4j’s Virtual Graph turns Cypher into SQL that runs on Databricks compute, which keeps execution and auditing inside the platform. PuppyGraph and GraphLake run their own distributed engines, which can traverse faster but add a system to operate.

Timeline

  1. 2023

    Graph queries on data lakes presented to the Trino community; SQL:2023 adds SQL/PGQ

  2. 2024

    PuppyGraph launches in March; ISO publishes GQL in April

  3. 2026

    Delta Lake graph lakehouse session (January), GraphLake paper (March), Neo4j Virtual Graph preview (June)

Sources13

Improve this page on GitHub