Declare which columns are nodes and edges. DeltaForge projects the graph in memory from the tables you already have. Query with Cypher. Join results back to SQL. No separate graph database.
Your table rows become graph edges; referenced keys become nodes
Tell DeltaForge which column is the source node and which is the target node. The graph is projected from those columns.
The graph is built on demand and held in the session, ready for Cypher queries and algorithm table functions without a round-trip to storage.
Use ordinary INSERT, UPDATE, DELETE on the underlying Delta tables. The graph rebuilds incrementally so Cypher sees the latest data.
MATCH, WHERE, RETURN for graph queries. All writes go through SQL on the Delta table, keeping a single transaction model.
Every algorithm runs inside the same SQL engine that reads your tables, not in a separately deployed query layer. Call one from a SELECT, join its output to any table, and feed it straight into a MERGE or a chart in one statement. 18 ship with GPU implementations selectable via the ON GPU Cypher hint.
graph_pagerank(), graph_articlerank(), graph_eigenvector(), graph_hits(), graph_betweenness(), graph_closeness(), graph_harmonic(), graph_degree()
graph_louvain(), graph_leiden(), graph_labelpropagation(), graph_components(), graph_scc(), graph_kcore(), graph_lcc(), graph_triangle_count(), graph_modularity(), graph_conductance()
graph_bridges(), graph_articulationpoints()
graph_shortest_path() (Dijkstra), graph_bellmanford(), graph_deltastepping(), graph_astar(), graph_yens(), graph_bfs(), graph_dfs(), graph_mst(), graph_randomwalk()
graph_knn(), graph_similarity() (Jaccard, Adamic-Adar, common neighbors)
graph_fastrp() (Fast Random Projection embeddings)
ON GPU Cypher hintEighteen algorithms ship with WGSL compute shaders that run on any cross-vendor wgpu device (NVIDIA, AMD, Intel, Apple). Numerically identical to the CPU path, verified against Neo4j + GDS 2.6.9 on Zachary's karate club.
PageRank, ArticleRank, Eigenvector, HITS, Betweenness, Harmonic, Louvain, Label Propagation, Connected Components, K-Core, LCC, Triangle Count, Modularity, Conductance, Bellman-Ford, Delta-Stepping, Random Walk, FastRP.
Leiden refinement, Bridges, Articulation Points, A*, Yen's K-shortest paths, Closeness, SCC, Shortest Path (Dijkstra), BFS, DFS, MST, KNN, Similarity, Degree. Sequential by construction; GPU offers no speedup.
ON GPU means "run on GPU or error". No silent CPU fallback. Below-threshold graphs override with ON GPU THRESHOLD 1; a missing GPU implementation errors with a clear message instead of producing inconsistent results.
Nodes and edges live in regular Delta tables; choose the column layout that fits
Structured columns for fixed-schema graphs. Best for analytics-heavy scans.
Structured edge columns with a property map for flexible attributes. Balances scan speed with schema flexibility.
Full graph structure in JSON columns for deeply nested or heterogeneous schemas.
Short answers to the questions teams ask before running graph workloads on the lake
Yes. The graph is projected from table columns, so openCypher MATCH queries run over Parquet and Delta tables in place. Nothing is exported to Neo4j or any separate graph store.
No. Community detection ships as SQL table functions: graph_louvain(), graph_leiden(), graph_labelpropagation() and seven more run against the projected graph, and their output joins back to any Delta table in the same SELECT.
Yes. Each algorithm is a SQL table function, so its output rows join with any Delta table in the same SELECT, ready for a MERGE or a dashboard query.
Walkthroughs and adjacent features for graph work on the lakehouse
A hands-on walkthrough of projecting a graph from existing tables and querying it with MATCH.
Finding communities with graph_louvain() and joining the clusters back to the source rows.
Expose the same projected graph and catalog to AI agents through the DeltaForge MCP server.
No separate graph database. No sync pipeline. Your Delta tables are the graph.