Graph Projections and In-Memory Graphs

Key Takeaways

Section 5.4 graph projections and in-memory graphs. The technical foundation that makes GDS algorithms possible and the three ways to get results out. Before any GDS algorithm can run, you need to create a graph projection. An in-memory copy of the subgraph you want to analyze. This is a deliberate design choice. Running algorithms on a separate in-memory copy means they don't block other queries running against the main database. There are two ways to create a projection. Native projections use a declarative config. You specify which node labels and relationship types to include their orientation and which properties to load. The syntax is shown on the left. It's fast because GDS can read directly from Neo4j's native label and relationship indices without executing cipher. Cipher projections use queries to define what goes into the graph. You provide a node query that returns node ids and labels and a relationship query that returns source and target ids plus any weight properties. This is more flexible. You can project computed properties, filter with wear clauses, combine multiple labels in complex ways, but it's slower because it has to execute cipher to build the projection. The comparison table sums it up. For standard projections on a clean, well-labeled graph, use native projections. They're significantly faster. For custom subsets, multi-step filtering, or computed properties, use cipher projections. When in doubt, start with native and switch to cipher only if you need the flexibility. One more thing worth knowing, always drop your projection when you're done with it. Projections consume memory. Call GDS.graph.drop with the graph name to release it. Every GDS algorithm supports three execution modes, and choosing the right one is more important than most people realize. The wrong choice can waste performance or leave you without the results you need. Stream mode returns results as a cipher result stream like any other yield statement. The algorithm runs, produces a result set, and you work with it using width and return. Nothing is persisted anywhere. Not to the projection, not to Neo4j. This is the mode for exploration. Run page rank to see which nodes score highest. Look at the numbers. Decide whether you need to do more. If you close the session, the results are gone. No cleanup needed. Mutate mode writes results to the in-memory projected graph as a new node property but not to the underlying Neo4j database. This is the mode for algorithm chaining. Imagine you want to run page rank then use the page rank score as input to a KNN similarity query. You mutate the page rank score onto the in-memory graph and the next GDS call can reference it. It's fast because everything stays in memory. When you're done, you can explicitly write the in-memory properties back to Neo4j using GDS.graph.right node properties. Write mode persists results directly and permanently to Neo4j as a property on the actual node. After a write, the score is immediately queryable in any cipher query. It's the slowest mode because it involves disk IO, but it's the right choice when you want those scores to be part of your production graph, available to your application, visible in Bloom, queryable by other teams. The simple decision rule. Use stream for exploration and one-off analysis. Use mutate when you're chaining multiple GDS algorithms together. Use write when you want the results to live in the graph permanently. Module 5 was dense. Let me pull it together into five things to remember. First, variable length paths unlock traversal power. Use the star syntax with an upper bound. Open bracket asterisk 1 to n close bracket. The built-in all shortest paths and shortest path functions cover most single query traversal needs without even touching GDS. Second call sub queries give you independent scopes. Aggregate within a subquery, combine different patterns with union and isolate per row computations. This is the pattern that replaces most multi-query application logic with a single cipher statement. Third, GDS algorithms run on in-memory projections. Project first. Choose native for speed. Cipher for flexibility. Then run. Page rank for influence betweenness for critical connectors. Luane for communities. Node similarity for structural neighbors. Fourth dystra for weighted shortest paths on any graph. A star for geographic routing where a latl lawn heristic is available. Both guarantee the optimal path. AAR is simply faster when it has a good heristic to work with. Fifth, choose your result mode deliberately. Stream for exploration. Mutate for chaining algorithms together in memory. Write to persist scores permanently to Neo4j for downstream use. In module six, we take everything we've built, modeled graphs, ontologies, algorithms, and connect them to large language models. Graph rag text to cipher knowledge graph construction from unstructured text. The most exciting chapter yet. See you there.