ConceptsEnterprise EditionNot available on AuraIntroduced in 2025.10
Scalability is a crucial aspect of database management, allowing a system to handle changing demands by adding and removing resources to meet the demands of a database’s workload. Neo4j supports multiple strategies to achieve scalability, enabling systems to handle larger datasets, more concurrent users, and higher query complexity without compromising performance or availability, i.e. the system’s resiliency. The three main strategies are:
-
Analytics clustering — for horizontal read scalability.
-
Composite databases — for federated queries and distributed data management.
-
Property sharding — for handling massive property-heavy graphs.
What is scalability?
Scalability is a system’s ability to handle an increasing workload without compromising performance. There are two primary methods to achieve scalability:
| Method | Description | Pros | Cons |
|---|---|---|---|
Vertical Scaling (Scaling Up / Down) |
Increase or decrease the capacity of a single server by adding or removing CPUs, memory, or storage. |
Simple to manage. |
|
Horizontal Scaling (Scaling Out / In) |
Distribute the workload by adding more servers or reduce the infrastructure by removing existing servers. |
|
More complex to manage. |
What is database scalability?
Database scalability is the ability of a database management system (DBMS) to handle changing demands. To scale properly, a database must apply strategies that cover all areas: data access, data manipulation in memory, and database computing.
Strategies include:
-
Vertical Scaling
-
Optimize usage (e.g., granular locks, partitioning)
-
Optimize physical resources (multi-threading, tiered storage)
-
-
Horizontal Scaling (distributed computing architectures):
-
Shared Everything: All servers share data and memory. Flexible, but prone to contention.
In this model, data is shared between disk and memory across all servers in a cluster. Requests are satisfied by any combination of servers. This approach introduces complexity, as the cluster must implement a way to avoid contention when multiple servers try to update the same data simultaneously. -
Shared Nothing: Each server manages its own partition (shard). More fault-tolerant, eliminates single points of failure.
Every update request is handled by a single cluster member, which eliminates single points of failure. Each part of the database on a single cluster member is called a shard.
-
What is graph database scalability?
Graph database scalability refers to the ability of a database to handle different amounts of data and workloads without compromising performance. It includes:
-
Data volume - involves ensuring a consistent SLA in both query and administration response times, even as the size of the data for storage and retrieval expands.
Volume depends on data type(s). Vectors occupy a large data space. -
Query volume
-
Read queries + write queries.
-
Queries and user concurrency — the aim is to ensure a linear response time during the execution of concurrent queries against the same database.
-
Query complexity — provide response time in line with the complexity of a query. The complexity of a query can be set by the combination of:
-
Steps to execute
-
Rows to retrieve
-
Total DB hits
-
Total memory allocation
-
Total execution time
-
-
-
Admin volume
-
Data ingestion/extraction — When scaling data ingestion/extraction, the goal is to maintain a linear response time when ingesting or extracting an increasing set of data. This objective remains true regardless of the volume of stored data, provided a similar data structure is used.
-
Multi-tenancy — In SaaS and AaaS environments, the scaling cost for tenants should exhibit linearity. For more general services, such as DBaaS (e.g., Aura), scalability should also be linear, considering all five scalability factors mentioned here.
-