Performance recommendations

Always specify the target database

Specify the target database on all queries, either with the database_ parameter in Driver.execute_query() or with the database parameter when creating new sessions. If no database is provided, the driver has to send an extra request to the server to figure out what the default database is. The overhead is minimal for a single query, but becomes significant over hundreds of queries.

Good practices

driver.execute_query("<QUERY>", database_="<DB NAME>")
driver.session(database="<DB NAME>")

Bad practices

driver.execute_query("<QUERY>")
driver.session()

Be aware of the cost of transactions

When submitting queries through .execute_query() or through .execute_read/write(), the server automatically wraps them into a transaction. This behavior ensures that the database always ends up in a consistent state, regardless of what happens during the execution of a transaction (power outages, software crashes, etc).

Creating a safe execution context around a number of queries obviously yields an overhead that is not present if the driver just shoots queries at the server and hopes they will get through. The overhead is small, but can pile up as the number of queries increases. For this reason, if your use case values throughput more than data integrity, you may extract further performance by running all queries within a single (auto-commit) transaction. You do this by creating a session and using session.run() to run as many queries as needed.

Privilege throughput over data integrity
with driver.session(database="neo4j") as session:
    for i in range(1000):
        session.run("<QUERY>")
Privilege data integrity over throughput
for i in range(1000):
    driver.execute_query("<QUERY>")
    # or session.execute_read/write() calls

Don’t fetch large result sets all at once

When submitting queries that may result in a lot of records, don’t retrieve them all at once. The Neo4j server can retrieve records in batches, and the driver can receive one batch and wait until it has been processed by the application before receiving another batch from the server. Lazy-loading a result spreads out network traffic and memory usage.

For convenience, .execute_query() always retrieves all result records at once (it is what the Eager in EagerResult stands for). To lazy-load a result, you have to use .execute_read/write() (or other forms of manually-handled transactions) and not cast the Result object to list when processing the result; iterate on it instead.

Example 1. Comparison between eager and lazy loading

Consider a query that results in 250 result records, and that the driver’s batch size is set to 100 (default is 1000).

Eager loading Lazy loading
  • The server has to read all 250 records from the storage before it can send even the first one the driver (i.e. it takes more time for the client to receive the first record).

  • Before any record is available to the application, the driver has to receive all 250 records.

  • The client has to hold in memory all 250 records.

  • The server reads the first 100 records and sends them to the driver.

  • The application can process records as soon as the first batch is transferred.

  • When the first batch has been processed, the server reads another batch and delivers it to the driver. Further records are delivered in further batches.

  • Waiting time and resource consumption (both client- and server-side) for the remaining records is deferred to when the application requests more records.

  • Resource consumption is bounded by at most 100 records.

Time and memory comparison between eager and lazy loading
import neo4j
from time import sleep, time
import tracemalloc



URI = "<URI for Neo4j database>"
AUTH = ("<Username>", "<Password>")

# Returns 250 records, each with properties
# - `output` (an expensive computation, to slow down retrieval)
# - `dummyData` (a list of 10000 ints, about 8 KB).
slow_query = '''
UNWIND range(1, 250) AS s
RETURN reduce(s=s, x in range(1,1000000) | s + sin(toFloat(x))+cos(toFloat(x))) AS output,
       range(1, 10000) AS dummyData
'''
# Delay for each processed record
sleep_time = 0.5


def main():
    with neo4j.GraphDatabase.driver(URI, auth=AUTH) as driver:
        driver.verify_connectivity()

        start_time = time()
        log('LAZY LOADING (execute_read)')
        tracemalloc.start()
        lazy_loading(driver)
        log(f'Peak memory usage: {tracemalloc.get_traced_memory()[1]} bytes')
        tracemalloc.stop()
        log('--- %s seconds ---' % (time() - start_time))

        start_time = time()
        log('EAGER LOADING (execute_query)')
        tracemalloc.start()
        eager_loading(driver)
        log(f'Peak memory usage: {tracemalloc.get_traced_memory()[1]} bytes')
        tracemalloc.stop()
        log('--- %s seconds ---' % (time() - start_time))


def lazy_loading(driver):

    def process_records(tx):
        log('Submit query')
        result = tx.run(slow_query)

        for record in result:
            log(f'Processing record {int(record.get("output"))}')
            sleep(sleep_time)  # proxy for some expensive operation

    with driver.session(database='neo4j') as session:
        processed_result = session.execute_read(process_records)


def eager_loading(driver):
    log('Submit query')
    records, _, _ = driver.execute_query(slow_query, database_='neo4j')

    for record in records:
        log(f'Processing record {int(record.get("output"))}')
        sleep(sleep_time)  # proxy for some expensive operation


def log(msg):
    print(f'[{round(time(), 2)}] {msg}')


if __name__ == '__main__':
    main()
Output
[1718014246.64] LAZY LOADING (execute_read)
[1718014246.64] Submit query
[1718014256.21] Processing record 0  (1)
[1718014256.71] Processing record 1
...
[1718014305.33] Processing record 98
[1718014305.84] Processing record 99
[1718014315.95] Processing record 100  (2)
[1718014316.45] Processing record 101
...
[1718014394.92] Processing record 248
[1718014395.42] Processing record 249
[1718014395.92] Peak memory usage: 37694 bytes
[1718014395.92] --- 149.2824890613556 seconds ---

[1718014395.92] EAGER LOADING (execute_query)
[1718014395.92] Submit query
[1718014419.82] Processing record 0  (3)
[1718014420.33] Processing record 1
...
[1718014468.9] Processing record 98
[1718014469.4] Processing record 99
[1718014469.9] Processing record 100  (4)
[1718014470.4] Processing record 101
...
[1718014544.02] Processing record 248
[1718014544.52] Processing record 249
[1718014545.02] Peak memory usage: 80222 bytes  (5)
[1718014545.02] --- 149.10213112831116 seconds ---  (6)
1 With lazy loading, the first record is available ~10 seconds after the query is submitted (i.e. as soon as the server has retrieved the first batch of 100 records).
2 It takes about the same time to receive the second batch as it took for the first batch (similar for subsequent batches).
3 With eager loading, the first record is available ~25 seconds after the query has been submitted submitted (i.e. after the server has retrieved all 250 records).
4 There’s no delay in between batches: the processing time between any two records is the same.
5 Memory usage is larger with eager loading than with lazy loading, because the application materializes a list of 250 records (while in lazy loading it’s never more than 100).
6 The total running time is practically the same, but lazy loading spreads that out across batches whereas eager loading has one longer waiting period. With lazy loading, the client could also stop requesting records after some condition is met, saving time and resources.

Route read queries to cluster readers

In a cluster, route read queries to secondary nodes. You do this by:

Good practices

driver.execute_query("MATCH (p:Person) RETURN p", routing_="r")
session.execute_read(lambda tx: tx.run("MATCH (p:Person) RETURN p"))

Bad practices

driver.execute_query("MATCH (p:Person) RETURN p")
# defaults to routing = writers
session.execute_write(lambda tx: tx.run("MATCH (p:Person) RETURN p"))
# don't ask to write on a read-only operation

Create indexes

Create indexes for properties that you often filter against. For example, if you often look up Person nodes by the name property, it is beneficial to create an index on Person.name. You can create indexes with the CREATE INDEX Cypher clause, for both nodes and relationships.

# Create an index on Person.name
driver.execute_query("CREATE INDEX person_name FOR (n:Person) ON (n.name)")

For more information, see Indexes for search performance.

Profile queries

Profile your queries to locate queries whose performance can be improved. You can profile queries by prepending them with PROFILE. The server output is available in the profile property of the ResultSummary object.

_, summary, _ = driver.execute_query("PROFILE MATCH (p {name: $name}) RETURN p", name="Alice")
print(summary.profile['args']['string-representation'])
"""
Planner COST
Runtime PIPELINED
Runtime version 5.0
Batch size 128

+-----------------+----------------+----------------+------+---------+----------------+------------------------+-----------+---------------------+
| Operator        | Details        | Estimated Rows | Rows | DB Hits | Memory (Bytes) | Page Cache Hits/Misses | Time (ms) | Pipeline            |
+-----------------+----------------+----------------+------+---------+----------------+------------------------+-----------+---------------------+
| +ProduceResults | p              |              1 |    1 |       3 |                |                        |           |                     |
| |               +----------------+----------------+------+---------+----------------+                        |           |                     |
| +Filter         | p.name = $name |              1 |    1 |       4 |                |                        |           |                     |
| |               +----------------+----------------+------+---------+----------------+                        |           |                     |
| +AllNodesScan   | p              |             10 |    4 |       5 |            120 |                 9160/0 |   108.923 | Fused in Pipeline 0 |
+-----------------+----------------+----------------+------+---------+----------------+------------------------+-----------+---------------------+

Total database accesses: 12, total allocated memory: 184
"""

In case some queries are so slow that you are unable to even run them in reasonable times, you can prepend them with EXPLAIN instead of PROFILE. This will return the plan that the server would use to run the query, but without executing it. The server output is available in the plan property of the ResultSummary object.

_, summary, _ = driver.execute_query("EXPLAIN MATCH (p {name: $name}) RETURN p", name="Alice")
print(summary.plan['args']['string-representation'])
"""
Planner COST
Runtime PIPELINED
Runtime version 5.0
Batch size 128

+-----------------+----------------+----------------+---------------------+
| Operator        | Details        | Estimated Rows | Pipeline            |
+-----------------+----------------+----------------+---------------------+
| +ProduceResults | p              |              1 |                     |
| |               +----------------+----------------+                     |
| +Filter         | p.name = $name |              1 |                     |
| |               +----------------+----------------+                     |
| +AllNodesScan   | p              |             10 | Fused in Pipeline 0 |
+-----------------+----------------+----------------+---------------------+

Total database accesses: ?
"""

Specify node labels

Specify node labels in all queries. This allows the query planner to work much more efficiently, and to leverage indexes where available. To learn how to combine labels, see Cypher → Label expressions.

Good practices

driver.execute_query("MATCH (p:Person|Animal {name: $name}) RETURN p", name="Alice")
with driver.session(database="<DB NAME>") as session:
    session.run("MATCH (p:Person|Animal {name: $name}) RETURN p", name="Alice")

Bad practices

driver.execute_query("MATCH (p {name: $name}) RETURN p", name="Alice")
with driver.session(database="<DB NAME>") as session:
    session.run("MATCH (p {name: $name}) RETURN p", name="Alice")

Batch data creation

Batch queries when creating a lot of records using the WITH and UNWIND Cypher clauses.

Good practice

Submit one single queries with all values inside
numbers = [{"value": random()} for _ in range(10000)]
driver.execute_query("""
    WITH $numbers AS batch
    UNWIND batch AS node
    MERGE (n:Number)
    SET n.value = node.value
    """, numbers=numbers,
)

Bad practice

Submit a lot of single queries, one for each value
for _ in range(10000):
    driver.execute_query("MERGE (:Number {value: $value})", value=random())
The most efficient way of performing a first import of large amounts of data into a new database is the neo4j-admin database import command.

Use query parameters

Always use query parameters instead of hardcoding or concatenating values into queries. Besides protecting from Cypher injections, this allows to better leverage the database query cache.

Good practices

driver.execute_query("MATCH (p:Person {name: $name}) RETURN p", name="Alice")
with driver.session(database="<DB NAME>") as session:
    session.run("MATCH (p:Person {name: $name}) RETURN p", name="Alice")

Bad practices

driver.execute_query("MATCH (p:Person {name: 'Alice'}) RETURN p")
# or
name = "Alice"
driver.execute_query("MATCH (p:Person {name: '" + name + "'}) RETURN p")
with driver.session(database="<DB NAME>") as session:
    session.run("MATCH (p:Person {name: 'Alice'}) RETURN p")
    # or
    name = "Alice"
    session.run("MATCH (p:Person {name: '" + name + "'}) RETURN p")

Concurrency

Use concurrency, either in the form of multithreading or with the async version of the driver. This is likely to be more impactful on performance if you parallelize complex and time-consuming queries in your application, but not so much if you run many simple ones.

Use MERGE for creation only when needed

The Cypher clause MERGE is convenient for data creation, as it allows to avoid duplicate data when an exact clone of the given pattern exists. However, it requires the database to run two queries: it first needs to MATCH the pattern, and only then can it CREATE it (if needed).

If you know already that the data you are inserting is new, avoid using MERGE and use CREATE directly instead — this practically halves the number of database queries.

Filter notifications

Glossary

LTS

A Long Term Support release is one guaranteed to be supported for a number of years. Neo4j 4.4 is LTS, and Neo4j 5 will also have an LTS version.

Aura

Aura is Neo4j’s fully managed cloud service. It comes with both free and paid plans.

Cypher

Cypher is Neo4j’s graph query language that lets you retrieve data from the database. It is like SQL, but for graphs.

APOC

Awesome Procedures On Cypher (APOC) is a library of (many) functions that can not be easily expressed in Cypher itself.

Bolt

Bolt is the protocol used for interaction between Neo4j instances and drivers. It listens on port 7687 by default.

ACID

Atomicity, Consistency, Isolation, Durability (ACID) are properties guaranteeing that database transactions are processed reliably. An ACID-compliant DBMS ensures that the data in the database remains accurate and consistent despite failures.

eventual consistency

A database is eventually consistent if it provides the guarantee that all cluster members will, at some point in time, store the latest version of the data.

causal consistency

A database is causally consistent if read and write queries are seen by every member of the cluster in the same order. This is stronger than eventual consistency.

NULL

The null marker is not a type but a placeholder for absence of value. For more information, see Cypher → Working with null.

transaction

A transaction is a unit of work that is either committed in its entirety or rolled back on failure. An example is a bank transfer: it involves multiple steps, but they must all succeed or be reverted, to avoid money being subtracted from one account but not added to the other.

backpressure

Backpressure is a force opposing the flow of data. It ensures that the client is not being overwhelmed by data faster than it can handle.

transaction function

A transaction function is a callback executed by an execute_read or execute_write call. The driver automatically re-executes the callback in case of server failure.

Driver

A Driver object holds the details required to establish connections with a Neo4j database.