GraphAcademy

Get started with Graph Data Science

Get started with the Graph Data Science library

GDS basic concepts

Working with algorithms

Essential projection techniques

List and drop graphs

Introduction

Now that you’ve practiced creating various types of projections—monopartite, bipartite, and multipartite—it’s time to learn how to manage them efficiently.

Throughout this course, you’ve been creating graph projections using gds.graph.project(). Each projection gets stored in GDS’s graph catalog—an in-memory store of all your projected graphs.

As you work with GDS, you’ll create multiple projections for different analyses. Managing these graphs efficiently is crucial for memory management, workflow organization, and cleanup.

In this lesson, you’ll learn three essential graph catalog operations: listing graphs, checking if a graph exists, and dropping graphs you no longer need.

By the end of this lesson, you will be able to:

  • List all graphs in the catalog

  • Check if a specific graph exists

  • Drop graphs to free up memory

Operation 1: Listing graphs

The gds.graph.list() procedure shows you all graphs currently stored in the catalog. It returns information about projected graphs including their names, node counts, relationship counts, memory usage, and schemas.

You’ll use this operation to check what graphs are available, verify a projection was created successfully, review memory usage across all graphs, and inspect graph schemas and properties.

Let’s start by listing all graphs in the catalog:

cypher
List all graphs in the catalog
CALL gds.graph.list() // (1)
YIELD graphName, nodeCount, relationshipCount, memoryUsage // (2)
RETURN graphName, nodeCount, relationshipCount, memoryUsage // (3)
ORDER BY graphName ASC // (4)

Query breakdown

  1. Call the graph list procedure

  2. Yield basic information about each graph

  3. Return the graph details

  4. Sort by graph name alphabetically

This returns basic information about every graph you’ve projected. The memoryUsage field shows how much heap memory each graph consumes.

You can also get detailed information about a specific graph by passing its name to the procedure:

cypher
List detailed information for a specific graph
CALL gds.graph.list('user-movie') // (1)
YIELD graphName, schema, degreeDistribution, density // (2)
RETURN graphName, schema, degreeDistribution, density // (3)

Query breakdown

  1. Call the graph list procedure for the 'user-movie' graph

  2. Yield detailed information fields

  3. Return the graph details

This returns extended information about the user-movie graph. The schema field contains node labels, relationship types, and properties.

The degreeDistribution field provides statistics about node connections like minimum, maximum, mean, and percentiles.

The density field tells you how connected the graph is by dividing the relationship count by the maximum possible relationships.

List your graphs

You’ve created several graphs in previous lessons. List them to see what’s in your catalog.

Run this query again to see all your graphs:

cypher
View all graphs with node and relationship counts
CALL gds.graph.list() // (1)
YIELD graphName, nodeCount, relationshipCount // (2)
RETURN graphName, nodeCount, relationshipCount // (3)
ORDER BY graphName ASC // (4)

Query breakdown

  1. Call the graph list procedure

  2. Yield graph name, node count, and relationship count

  3. Return the graph statistics

  4. Sort by graph name alphabetically

Scroll through the results and you should see several graphs including actors-network from the monopartite lessons, user-movie and actor-movie from the bipartite lessons, and any others you’ve created along the way.

Now get detailed information about just one of your graphs by completing the query below.

Remember, to list a specific graph, you need to use the .list operator and provide the name of the graph.

cypher
Get details for a specific graph (replace ?????)
CALL gds.graph.?????(?????) // (1)
YIELD graphName, schema // (2)
RETURN graphName, schema // (3)

Query breakdown

  1. Call the graph list procedure with graph name (fill in procedure and name)

  2. Yield the graph name and schema

  3. Return the graph details

If you need help, feel free to check the dropdown below.

Details
cypher
Solution: List details for user-movie graph
CALL gds.graph.list('user-movie') // (1)
YIELD graphName, schema // (2)
RETURN graphName, schema // (3)

  1. Call the graph list procedure for 'user-movie'

  2. Yield the graph name and schema

  3. Return the graph details

Key points:

  • Use gds.graph.list() with no arguments to list all graphs

  • Use gds.graph.list('graph-name') to get details about a specific graph

  • YIELD the fields you’re interested in (graphName, schema, memoryUsage, etc.)

Simply running CALL gds.graph.list() is also perfectly fine. It will return all information about your graphs in a slightly less readable format.

cypher
List all graphs (full output)
CALL gds.graph.list() // (1)

Call the graph list procedure to return all graph information

Operation 2: Checking if a graph exists

The gds.graph.exists() procedure checks whether a specific graph is in the catalog. It returns true if a graph with the given name exists, false otherwise.

You can use this operation before creating a graph to avoid errors if it already exists, before running an algorithm to verify the graph is available, or in conditional logic and scripts.

Let’s check if a graph exists using the procedure:

cypher
Check if a graph exists
CALL gds.graph.exists('user-movie') // (1)
YIELD graphName, exists // (2)
RETURN graphName, exists // (3)

Query breakdown

  1. Call the graph exists procedure for 'user-movie'

  2. Yield the graph name and existence status

  3. Return the result

You can check multiple graphs at once by using UNWIND:

cypher
Check multiple graphs at once
UNWIND ['user-movie', 'user-genre', 'nonexistent-graph'] AS graph // (1)
CALL gds.graph.exists(graph) // (2)
YIELD graphName, exists // (3)
RETURN graphName, exists // (4)

Query breakdown

  1. Unwind a list of graph names to check

  2. Call the exists procedure for each graph

  3. Yield the graph name and existence status

  4. Return the results for all graphs

You can also use gds.graph.exists() as a function directly in queries:

cypher
Use exists as a function
RETURN gds.graph.exists('user-movie') AS userMovieExists,
    gds.graph.exists('fake-graph') AS fakeGraphExists // (1)

Query breakdown

Return existence status for multiple graphs using exists as a function

Check graph existence

Check whether the graphs you’ve been working with exist in the catalog.

Complete the query below with graphs from your graphs list to check if multiple graphs exist:

cypher
Check existence of multiple graphs (replace ????)
UNWIND [????, ????, ????] AS graph // (1)
CALL gds.graph.exists(graph) // (2)
YIELD graphName, exists // (3)
RETURN graphName, exists // (4)

Query breakdown

  1. Unwind a list of graph names (fill in 3 graph names to check)

  2. Call the exists procedure for each graph

  3. Yield the graph name and existence status

  4. Return the results

If you need help filling in the placeholders, check the solution in the dropdown below.

Details
cypher
Solution: Check multiple graphs
UNWIND ['user-movie', 'user-genre', 'nonexistent-graph'] AS graph // (1)
CALL gds.graph.exists(graph) // (2)
YIELD graphName, exists // (3)
RETURN graphName, exists // (4)

  1. Unwind a list of three graph names to check

  2. Call the exists procedure for each graph

  3. Yield the graph name and existence status

  4. Return the results for all graphs

Key points:

  • Use gds.graph.exists('graph-name') to check if a graph exists

  • YIELD graphName and exists (boolean) fields

  • Can also use as a function: gds.graph.exists('graph-name') returns true/false

Operation 3: Dropping graphs

The gds.graph.drop() procedure removes a graph from the catalog and releases the heap memory it was using.

You’ll use this operation to free up memory for new projections, remove outdated or incorrect projections, and clean up once analyses are complete.

An important detail: dropping a graph only removes it from GDS’s in-memory catalog. It does not affect your Neo4j database. Any data you wrote back using .write() mode remains in the database.

Let’s drop a graph from the catalog:

cypher
Drop a graph from the catalog
CALL gds.graph.drop('user-movie') // (1)
YIELD graphName, nodeCount, relationshipCount // (2)
RETURN graphName, nodeCount, relationshipCount // (3)

Query breakdown

  1. Call the drop procedure to remove 'user-movie' from the catalog

  2. Yield information about the dropped graph

  3. Return the graph statistics

This returns information about the dropped graph, confirming what was removed.

By default, if you try to drop a graph that doesn’t exist, GDS raises an error. You can suppress this error by adding false:

cypher
Drop with error suppression
CALL gds.graph.drop('nonexistent-graph', false) // (1)
YIELD graphName // (2)

Query breakdown

  1. Drop the graph with error suppression (false means don’t fail if missing)

  2. Yield the graph name

The second parameter false means "don’t fail if the graph is missing." This is useful in cleanup scripts.

Drop a graph

You have several graphs from previous lessons—let’s remove one to free up memory.

Step 1: First, list all your graphs to see what’s available:

cypher
List all graphs (replace ?????)
CALL gds.?????.?????() // (1)
YIELD ?????, ????? // (2)
RETURN ?????, ????? // (3)

Query breakdown

  1. Call the graph list procedure (fill in the procedure name)

  2. Yield graph information fields (fill in field names)

  3. Return the graph information

Step 2: Choose a graph you no longer need (like movie-genre or actor-collaboration) and drop it:

cypher
Drop a graph (replace ?????)
CALL gds.?????.?????(?????) // (1)
YIELD graphName, memoryUsage // (2)
RETURN graphName, memoryUsage // (3)

Query breakdown

  1. Call the graph drop procedure with graph name (fill in procedure and name)

  2. Yield the graph name and memory usage

  3. Return the dropped graph information

Step 3: Verify it’s gone by listing all graphs again or checking existence:

cypher
Verify graph was dropped (replace ?????)
RETURN gds.?????.?????(?????) AS exists // (1)

Query breakdown

Call the exists function with graph name (fill in function and name) to verify deletion

You can find the full solution in the dropdown below.

Details

Step 1: List all graphs

cypher
Solution: List all graphs
CALL gds.graph.list() // (1)
YIELD graphName, memoryUsage // (2)
RETURN graphName, memoryUsage // (3)

  1. Call the graph list procedure

  2. Yield the graph name and memory usage

  3. Return the graph information

Step 2: Drop a graph

cypher
Solution: Drop movie-genre graph
CALL gds.graph.drop('movie-genre') // (1)
YIELD graphName, memoryUsage // (2)
RETURN graphName, memoryUsage // (3)

  1. Call the drop procedure to remove 'movie-genre' from the catalog

  2. Yield the graph name and memory usage

  3. Return the dropped graph information

Step 3: Verify it’s gone

cypher
Solution: Verify graph was dropped
RETURN gds.graph.exists('movie-genre') AS exists // (1)

  1. Check if the 'movie-genre' graph still exists (should return false)

Key points:

  • Use gds.graph.list() to see what graphs exist

  • Use gds.graph.drop('graph-name') to remove a graph

  • Use gds.graph.exists('graph-name') to verify it’s gone

  • Dropping only affects the in-memory catalog, not your database

Best practices

As you work with GDS, you’ll accumulate projections in memory. List graphs regularly to monitor memory usage and track your projections. Drop unused graphs to free up memory, especially when working with large datasets.

Use meaningful names for your graphs so you can easily identify them in the catalog. Names like user-movie-ratings-2024 are much clearer than graph1 or temp.

When writing automated workflows or scripts, check existence before dropping to avoid errors:

cypher
Safe drop for scripts
CALL gds.graph.drop('my-graph', false) // (1)

Query breakdown

Drop graph with error suppression (won’t fail if graph doesn’t exist)

What’s next

You now know how to manage graphs in the GDS catalog: listing, checking existence, and dropping them. These operations are essential for efficient memory management and workflow organization.

In the next lesson, you’ll put these skills to the test with a challenge that requires you to clean up the rest of your graph catalog independently.

Check your understanding

When to Drop Graphs

You’ve learned that gds.graph.drop() removes graphs from the catalog and frees up memory.

When would it be most appropriate to drop a graph?

  • ❏ Immediately after running an algorithm, because the results are already stored

  • ✓ After completing your analysis when you no longer need the projection

  • ❏ Before running every algorithm to ensure clean results

  • ❏ Never—graphs should remain in the catalog for future reference

Hint

Think about the relationship between projections and algorithms. Can you run multiple algorithms on the same projection? Does the projection contain the algorithm results?

Solution

After completing your analysis and no longer needing the projection.

Graph projections are reusable—you can run multiple algorithms on the same projection without recreating it. This is one of the key benefits of GDS’s Project → Run → Write workflow.

You should drop graphs when:

  • You’ve finished all planned analyses on that projection

  • You need to free up memory for new projections

  • You want to recreate a projection with different configurations

Dropping graphs immediately after running algorithms would force you to recreate projections unnecessarily. Keeping every projection indefinitely could consume excessive memory.

The key is balancing reusability with memory management based on your workflow needs.

Summary

The graph catalog stores all your in-memory projections. Three key operations help you manage it:

  • gds.graph.list(): View all graphs or get detailed information about a specific graph

  • gds.graph.exists(): Check if a graph exists before using it

  • gds.graph.drop(): Remove graphs to free memory

These operations are essential for managing memory and organizing your GDS workflows effectively.

Chatbot

How can I help you today?