Store formats

Neo4j’s storage engine supports several store formats that describe how data is written to disk. 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 default format for Community Edition.

standard and high_limit formats are deprecated in 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.

For information on store formats in Neo4j 4.4, see Neo4j Admin and Neo4j CLI → Neo4j Admin → Display store information.

Available store formats

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

Block

Enterprise Edition+

Default format unless db.format is specified.
Performance: Fast queries; uses advanced data structures and inlining techniques for better data locality. Uses dynamic records and tree structures to handle "growing" data efficiently.
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.
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.
Supported migration paths to other store formats: Although it is not recommended, you can change your store format from block to aligned or high_limit. Note that high_limit is deprecated. The aligned format has lower limits than block, so your graph must fit within those reduced limits.

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.
Supported migration paths to other store formats: You can change your store format from aligned to block or high_limit. Note that the high_limit format is deprecated, therefore, it is not recommended to migrate to it.

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.
Supported migration paths to other store formats: You can migrate to the block format only.

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.
Supported migration paths to other store formats: You can change your store format from standard to aligned, block, or high_limit. However, it is not recommended to migrate to the high_limit format as it is deprecated.

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.
From which store formats can I migrate, and to which formats?
For information about supported migration paths, refer to Neo4j Admin → Migrate a database.

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

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

The block format is the default format for Enterprise Edition due to its superior performance and scalability. Therefore, migrating all databases to block format is recommended to ensure optimal performance.
The block format supports token names (including node labels, property keys, and relationship type names) of any length up to the GQL identifier max length of 16,383 characters. Thus, token names must adhere to this length limit when migrating from aligned to block format.

standard and high_limit formats are deprecated in 5.23 and will be removed in a future release. For more information, see Format deprecations.

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 with the --include-metadata=all option to include all users and roles associated with it. For example:
```
bin/neo4j-admin database backup mydb --to-path=/path/to/your-backup-folder --include-metadata=all
```
The command creates a backup archive that contains both the database and the metadata associated with it.
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
Deprecated in 5.23

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
Deprecated in 5.23

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)

Stored data elements

The Neo4j graph data model consists of nodes, relationships, properties, and their data. The following data is stored for each element:

Nodes: a unique ID, a collection of labels (a node can have many labels or no labels), a collection of properties, and a collection of relationships (a node can have many relationships or no relationships).
Relationships: a unique ID, one type, a source node, a target node, and a collection of properties.
Properties: key-value pairs.

All graph data files are stored under $NEO4J_HOME/data/databases/databasename.

Block format store files

In block format, all graph elements are stored in a set of store files with the prefix block.. The following is an overview of the three most important store types, the files associated with them, the data they contain, the size of each record, and what they are used for.

Small store

block.x1.db: The primary store file that holds the initial data for nodes and relationships. In many datasets, the majority of all nodes fit in this store. When a node is created, a static block of size 128 B is created in this file at offset = 128 B * nodeId. It constists of two 64 B records: the node-data record stores the labels and node properties, and the relationship-data record stores the relationships and relationship data connected to this node. The encoding attempts to fit as much data into this block as possible, typically up to 10 labels, 6-7 properties, and up to 5 relationships. The amount of data that fits depends heavily on the type and size of the data. If you have more labels, but no properties or small properties, more labels will fit, and vice versa. The same applies to relationships. You can fit more relationships if there are fewer relationship properties, and vice versa. Keep in mind that if no data is present, the block still occupies 128 B. This block persists as long as the node exists.

Dynamic stores

Dynamic stores are used when the data connected to a node or relationship exceeds the capacity of the small store. The following dynamic store files exist:

block.node.xd.db: This file stores dynamic records for nodes. When the label or property data of a node exceeds the 64 B capacity of the record in the block.x1.db store, a record is allocated in this file. The size of the dynamic record is defined as size = X * 128, where X is chosen to be large enough to fit all labels and properties, with a maximum total size of 8192 B. The record in block.x1.db stores a reference to this dynamic record. As node data is added or removed, this record adapts to the new size, possibly relocating in the process. This record can typically contain hundreds of labels or properties.
block.relationship.xd.db: Similar to the node dynamic store, a record is allocated in this file when the relationship data exceeds the 64 B capacity of the record in the block.x1.db store or a node has at least one dense relationship. The size of this record also adapts to the total size of the relationship data, with a maximum size of 2047 B. The record in block.x1.db stores a reference to this dynamic record. This record can typically contain hundreds of relationships.
block.big_values.db: All properties of total size < ~31 B are inlined with the node and relationship data in the small or dynamic stores.
Properties exceeding 31 B when encoded, typically longer strings or arrays, are stored in this file, and a reference is placed in the value’s stead. The size of these records adapts to the encoded size of the property value, where the size = X * 64 B, with a maximum record size of 8192 B. If the encoded size of a property exceeds the maximum record size, the data is split into multiple records and linked together as a linked list. See Reuse of space for large property values in block format for more details.

Dense stores

When the data connected to nodes and relationships exceeds the capacity of both the small and dynamic stores, the data is stored in the dense store files. It is based on a multi-root generational B+ tree structure that allows for efficient storage and retrieval of large amounts of data, where each node has a separate root. The following dense store files exist:

block.relationship.dense.db: Relationship dense store holds relationships for nodes with a large number of relationships. When the relationship data of a node exceeds the maximum size of the dynamic relationship record, the overflowing relationships are moved to this store. This utilizes a tree structure, sorted by relationship type and direction for any given node. A node can have some relationships in the block.x1.db or block.relationship.xd.db store and others in the dense store. All relationships of the same type will always reside in the same store. There is no upper limit on how many relationships can be placed in the dense store for any given node.
block.huge.db: Huge store holds extremely large amounts of label or property data. When a node or relationship contains more label or property data than can fit in any other store, it ends up in the huge store. This typically occurs with entities containing thousands of properties.