Neo4j GDS Certification: GDS Library study guide

What the GDS Library domain tests

This domain covers installing and operating the GDS library: plugin deployment, configuration, procedure access, version checks, and client usage. It tests whether you can get GDS running and call it safely.

Core rules

GDS is a Neo4j plugin. Installation differs by deployment: Neo4j Desktop adds it as a plugin, Docker can use NEO4J_PLUGINS='["graph-data-science"]', and manual installs place the JAR in the plugins directory.
Procedures are namespaced under gds.*. If procedure security is restricted, allow the GDS procedures explicitly, for example dbms.security.procedures.unrestricted=gds.*.
Verify availability with CALL gds.version() and inspect projected graphs with CALL gds.graph.list().
The Python client graphdatascience wraps GDS procedures; it still requires a running Neo4j instance with the plugin.
Memory settings matter: projections and algorithms consume heap, and estimates help size workloads before execution.

Worked example

A Docker-based setup:

NEO4J_PLUGINS='["graph-data-science"]'
NEO4J_dbms_security_procedures_unrestricted=gds.*

After startup, verify:

CALL gds.version();
CALL gds.graph.project('g', 'Person', 'KNOWS');
CALL gds.graph.list();

Reasoning: the plugin must load before any gds.* procedure exists; unrestricted access prevents procedure-not-allowed errors in restricted setups; gds.version() confirms the library is active; gds.graph.list() confirms projection state and memory use.

Traps

Installing only the Python client and expecting algorithms to run without the server plugin.
Forgetting the procedure allowlist in secured deployments.
Confusing gds.version() with the Neo4j database version.
Underestimating heap for large projections and algorithm runs.
Assuming a client connection string alone proves GDS is installed.