Store formats

Neo4j’s storage engine supports several store formats that describe how data is written to disk. Starting from 5.23, block format is the recommended format for Enterprise Edition due to its superior performance and scalability. block format uses advanced data structures and inlining techniques to enhance data locality, which leads to better resource utilization.

aligned is the recommended format for Community Edition.

standard and high_limit formats are deprecated starting from Neo4j 5.23. It is not recommended to use these formats for new databases. For more information on the deprecation and timeline for the eventual removal of these formats, see Format deprecations.

Available store formats

Here’s an overview of the available formats and their features:

Block

Enterprise Edition GA in Neo4j 5.16

Default format from Neo4j 5.22 for new databases (unless db.format is specified).
Performance: Fast queries; uses advanced data structures and inlining techniques for better data locality.
Memory efficiency: Optimized collocation of data, which allows more related data to be fetched by fewer read operations; enhancing resource utilization. Block format means a few pages need to be loaded to serve a query, i.e. fewer page faults and less IO.
Property access: Properties are stored in blocks with their nodes and relationships drastically reducing the amount of pointer chasing required to access properties.
Entity limits: Able to run graphs at large scales. Supports the highest limits at the time of writing. See Block format entity limits for details.
Introduced in 5.25 Supports token names (including label, property key, and relationship type names) of any length up to the GQL identifier max length of 16,383 characters.
Future-proofing: Designed to be extended and improved without requiring store migrations. New features such as data types, or performance enhancements are available without rewriting the store.

Aligned

Default format in Community Edition and for all new databases in Enterprise Edition prior to Neo4j 5.22.
Performance: Performs better than standard but requires slightly more disk space.
Memory efficiency: Based on standard but with improved memory efficiency.
Property access: Stores graph data in linked list-like structures on disk.
Entity limits: Supports graphs within some limits. See Aligned format entity limits for details.

Standard

Deprecated in 5.23

Performance: Basic, foundational format.
Property access: Stores graph data in linked list-like structures on disk.
Entity limits: Supports graphs within some limits. See Standard format entity limits for details.
For information on deprecation and eventual removal, see Format deprecations.

High_limit

Enterprise Edition Deprecated in 5.23

Performance: Performs slightly worse than standard and requires more disk space, but allows more nodes and relationships.
Memory efficiency: Based on standard but with improved memory efficiency.
Property access: Stores graph data in linked list-like structures on disk.
Entity limits: From the record formats, supports the highest limits at the time of writing. For more information, see High_limit format entity limits.
For information on deprecation and eventual removal, see Format deprecations.

Format deprecations

standard and high_limit formats are deprecated starting from Neo4j 5.23.

block format provides better performance and scalability than the deprecated formats. They will remain part of the product throughout the v5 and vNext server lifecycles. The last version of Neo4j to include these formats will be vNext.LTS which is planned for release in November 2026. LTS versions of Neo4j are supported for 3 years following their release. This means that support for standard and high_limit formats is planned to end in November 2029.

It is recommended that Enterprise Edition users migrate all databases to block format at their earliest convenience to ensure the best possible performance. For more information, see Changing the store format of existing databases.

FAQ

How can I find out the format of my database?
You can use the SHOW DATABASES YIELD name, store Cypher command to get information about the store format of a database. See Show detailed information for a particular database for a detailed example.
When will support for standard and high_limit formats end?
The last version of Neo4j to include these formats will be an LTS release planned for November 2026, which will be supported for three years until November 2029.
How can I change the store format of my database?
For information on changing the store format of an existing database, see Changing the store format of existing databases.

How to set the database store format

You can either set the store format when creating a new database or change the store format of an existing database.

Creating new databases

In versions previous to Neo4j 5.22, the default store format for all new databases is aligned. From Neo4j 5.22, block is the default format for all newly-created databases as long as they do not have the db.format setting specified.
If you want to change it, you can set a new value for the db.format configuration in the neo4j.conf file.
You can also create a new database on a specific store format by passing the new format as an argument to the command creating the database, for example, neo4j-admin database import full or neo4j-admin database copy commands, or by using storeFormat: option in the Cypher command CREATE DATABASE.

The following examples show how to create a new database on the block store format. However, the same applies to other formats.

Specify the store format when importing a database using the neo4j-admin database import full command

bin/neo4j-admin database import full ... --format=block blockdb

Specify the store format when copying a database using the neo4j-admin database copy command

bin/neo4j-admin database copy --to-format="block" mydb blockdb

Specify the store format when creating a new database using the CREATE DATABASE Cypher statement

CREATE DATABASE blockdb OPTIONS {storeFormat: 'block'}

Changing the store format of existing databases

Starting from 5.23, block format is the preferred format for Enterprise Edition due to its superior performance and scalability. Therefore, migrating all databases to block format is recommended to ensure optimal performance.

Be aware that changing the store format changes the internal IDs assigned to nodes and relationships. This is because the ID represents the element’s physical location in the store file.

Changing the store format is an IO-intensive offline operation, which re-writes all data in the new format. Therefore, it requires that:

There is enough disk space for both old and new copies of the database. During the migration to block format, the database is inherently compacted. Therefore, the disk space required for the migration is approximately the same as the size of the database. You can use the database store size metrics to determine your available disk space and potentially reusable space.
The graph fits within the new format’s entity limits.

For large databases changing the store format can be a time-consuming operation and will also require any indexes to be re-populated. The time required depends on the size of the database, number of indices, speed of the storage devices, and the amount of available memory. For example, a 100GB database might take 10 minutes in optimal conditions, or over an hour in the worst case. Therefore, it is recommended to perform a dry run on a backup to estimate the required time for the migration.

In a standalone server

Changing the store format of an existing database in a standalone server requires the database to be offline. The following steps assume that you want to migrate the database called mydb to block format but the same steps apply to other formats.

Stop the database using the Cypher command STOP DATABASE mydb.

Change the store format of the stopped database using one of the following options:

Migrate an existing database using neo4j-admin database migrate command.

You do not need to run neo4j-admin database copy with the --compact-node-store option prior to running neo4j-admin database migrate. The database is inherently compacted during the migration process.

For example:

bin/neo4j-admin database migrate --to-format="block" mydb

Pass the new store format as an argument when using the neo4j-admin database copy command to create a copy of an existing database. You can also set the --copy-schema option to automatically copy the schema definitions. For example:
```
bin/neo4j-admin database copy --to-format="block" mydb blockdb --copy-schema
```

After the successful completion, start the database using the Cypher command START DATABASE mydb. Indexes are populated the first time the database is started, which might take some time if there are property uniqueness constraints.

In a cluster

Changing the store format of an existing database in a cluster requires that you restore a backup of the database that you want to migrate on one of the servers, and then, use that server as a designated seeder for the other cluster members to copy that database from.

The following steps assume that you want to migrate the database called mydb to block format but the same steps apply to other formats. The database is hosted on three servers in primary mode.

On one of the servers, server01

In Cypher Shell, put the database that you want to migrate in read-only mode using the Cypher command ALTER DATABASE databasename SET ACCESS READ ONLY. For example:
```
@system> ALTER DATABASE mydb SET ACCESS READ ONLY;
```
In your command-line tool, back up that database using the neo4j-admin database backup command. For example:
```
bin/neo4j-admin database backup mydb --to-path=/path/to/your-backup-folder --include-metadata=all
```
Back in Cypher Shell, drop the database to delete it and all users and roles associated with it:
```
@system> DROP DATABASE mydb;
```

In the command-line tool, restore the backup that you created using the neo4j-admin database restore command:

bin/neo4j-admin database restore --from-path=/path/to/your-backup-folder/mydb-2024-03-05T11-26-38.backup mydb

Migrate the restored database to block format:

bin/neo4j-admin database migrate --to-format="block" mydb

In Cypher Shell, run SHOW SERVERS to find the server ID of server01. Cross-reference the address to find the server ID. Use any database to connect.
```
SHOW SERVERS YIELD serverId, name, address, state, health, hosting
```

On one of the servers:

Use the system database and create the migrated database mydb using the server ID of server01. The topology of mydb is stored in the system database and when you create it, it is allocated according to the default topology (which can be shown with CALL dbms.showTopologyGraphConfig). For more information, see Designated seeder.
```
CREATE DATABASE mydb OPTIONS {existingData: 'use', existingDataSeedInstance: '<server01 id>'}
```
Verify that the database is created and available using the Cypher command SHOW DATABASE mydb.
After the successful completion, restore the roles and permissions. For more information, see Restore users and roles metadata.

Verify the store format

You can verify the store format of a database using the following Cypher:

SHOW DATABASES YIELD name, store

Result

+----------------------------------+
| name      | store                |
+----------------------------------+
| "blockdb" | "block-block-1.1"    |
| "neo4j"   | "record-aligned-1.1" |
| "system"  | "record-aligned-1.1" |
+----------------------------------+

Additionally, you can use the neo4j-admin database info command to get detailed information about the store format of a database. For details, see Display store information.

Store formats and entity limits

The following tables show the format and Neo4j version compatibility and the limits of the different store formats:

Block format

Table 1. Block format and Neo4j version compatibility
Name	Store format version	Introduced in	GA from	Default in
`BLOCK_V1`	`block-block-1.1`	`5.14.0`	`5.16.0`	`5.22.0`

Table 2. Block format entity limits
Name	Limit
Nodes	`2^48` (281 474 976 710 656)
Relationships	`∞` (no defined upper bound)
Properties	`∞` (no defined upper bound)
Labels	`2^31` (2 147 483 648)
Relationship types	`2^30` (1 073 741 824)
Property keys	`2^31` (2 147 483 648)

Aligned format

Table 3. Aligned format and Neo4j version compatibility
Name	Store format version	Introduced in	Default in
`ALIGNED_V5_0`	`record-aligned-1.1`	`5.0.0`	CE, EE < Neo4j 5.22
`ALIGNED_V4_3`	`AF4.3.0`	`4.3.0`	`5.0.0`
`ALIGNED_V4_1`	`AF4.1.a`	`4.1.0`	`5.0.0`

Table 4. Aligned format entity limits
Name	Limit
Property keys	`2^24` (16 777 216)
Nodes	`2^35` (34 359 738 368)
Relationships	`2^35` (34 359 738 368)
Properties	`2^36` (68 719 476 736)
Labels	`2^31` (2 147 483 648)
Relationship types	`2^16` (65 536)
Relationship groups	`2^35` (34 359 738 368)

Standard format

For information on deprecation and eventual removal, see Format deprecations.

Table 5. Standard format and Neo4j version compatibility
Name	Store format version	Introduced in	Unsupported from
`STANDARD_V5_0`	`record-standard-1.1`	`5.0.0`
`STANDARD_V4_3`	`SF4.3.0`	`4.3.0`	`5.0.0`
`STANDARD_V4_0`	`SF4.0.0`	`4.0.0`	`5.0.0`
`STANDARD_V3_4`	`v0.A.9`	`3.4.0`	`5.0.0`

Table 6. Standard format entity limits
Name	Limit
Property keys	`2^24` (16 777 216)
Nodes	`2^35` (34 359 738 368)
Relationships	`2^35` (34 359 738 368)
Properties	`2^36` (68 719 476 736)
Labels	`2^31` (2 147 483 648)
Relationship types	`2^16` (65 536)
Relationship groups	`2^35` (34 359 738 368)

High_limit format

For information on deprecation and eventual removal, see Format deprecations.

Table 7. High_limit format and Neo4j version compatibility
Name	Store format version	Introduced in	Unsupported from
`HIGH_LIMIT_V5_0`	`record-high_limit-1.1`	`5.0.0`
`HIGH_LIMIT_V4_3_0`	`HL4.3.0`	`4.3.0`	`5.0.0`
`HIGH_LIMIT_V4_0_0`	`HL4.0.0`	`4.0.0`	`5.0.0`
`HIGH_LIMIT_V3_4_0`	`vE.H.4`	`3.4.0`	`5.0.0`
`HIGH_LIMIT_V3_2_0`	`vE.H.3`	`3.2.0`	`5.0.0`
`HIGH_LIMIT_V3_1_0`	`vE.H.2`	`3.1.0`	`5.0.0`
`HIGH_LIMIT_V3_0_6`	`vE.H.0b`	`3.0.6`	`5.0.0`
`HIGH_LIMIT_V3_0_0`	`vE.H.0`	`3.0.0`	`5.0.0`

Table 8. High_limit format entity limits
Name	Limit
Property keys	`2^24` (16 777 216)
Nodes	`2^50` (1 Quadrillion)
Relationships	`2^50` (1 Quadrillion)
Properties	`2^50` (1 Quadrillion)
Labels	`2^31` (2 147 483 648)
Relationship types	`2^24` (16 777 216)
Relationship groups	`2^50` (1 Quadrillion)