Indexes in Neo4j 4.x

This section contains necessary information about indexes in different versions of Neo4j.

Indexes are automatically updated to the most recent index provider and rebuilt. The only exception are the 3.5 indexes that were previously using Lucene for single-property strings. They are upgraded to a fallback version that uses Lucene for those properties, and they have to be rebuilt. For details on creating, using, and dropping b-tree indexes, see Cypher^® Manual 4.0 → Indexes for search performance.

Тhe neo4j-admin copy command does not copy the schema store. Therefore, if following the path Neo4j 3.5 (Community or Enterprise) → Neo4j 4.x Enterprise, you have to recreate all indexes and constraints by running the Cypher commands that the neo4j-admin copy operation outputs. For more information on how to do that, see Tutorial: Back up and copy a database.

Index providers changes

The following table provides details on the index providers mapping:

Index provider in 3.5 Index provider in 4.x

Index provider in 3.5	Index provider in 4.x
`native-btree-1.0`	`native-btree-1.0`
`lucene+native-2.0`	`native-btree-1.0`
`lucene+native-1.0`	`lucene+native-3.0`
`lucene-1.0`	`lucene+native-3.0`

native-btree-1.0

lucene+native-2.0

native-btree-1.0

lucene+native-1.0

lucene+native-3.0

lucene-1.0

lucene+native-3.0

Memory allocation

Depending on what index providers were used previously, the upgrade of indexes may change the distribution of memory utilization. In a database with many indexes, a significant amount of memory may have been reserved for Lucene. Therefore, it is recommended to run neo4j-admin memrec --database before and after migration, and adjust memory settings in accordance with the findings. It might be necessary to allocate some of the memory reserved to Lucene back to the page cache. For a detailed description on how memory is allocated and used, refer to Operations Manual → Memory configuration and Operations Manual 4.0 → Capacity planning in particular.

Property size limits

Between 3.5 and 4.x, some changes have been made in how large a key (a property) can be in a b-tree index. These changes are only relevant for indexes that use the index providers lucene-1.0 or lucene+native-1.0 in 3.5, and hold large strings or large arrays.

Table 1. Property size limits for index providers in 3.5
Index and property type	`lucene-1.0`	`lucene+native-1.0`	`lucene+native-2.0`	`native-btree-1.0`
Single property strings	~32kB	~32kB	~4kB	~4kB
Single property arrays	~32kB	~32kB	~4kB	~4kB
Multiple properties	~32kB per property	~32kB per property	~4kB for properties combined	~4kB for properties combined

Table 2. Property size limits for index providers in 4.x
Index and property type	`lucene+native-3.0`	`native-btree-1.0`
Single property strings	~32kB	~8kB
Single property arrays	~8kB	~8kB
Multiple properties	~8kB for properties combined	~8kB for properties combined

There is no workaround in 4.x to index arrays or multiple properties larger than ~8kB. For more information about what happens when this property size limit is reached, see Operations Manual 4.0 → Limitations on key size.

Explicit indexes

Support for explicit indexes has been removed from 4.0 onwards and the functionality has been replaced by full-text indexes. For details, see Cypher Manual 4.0 → Indexes to support full-text search.

Token lookup indexes

With Neo4j 4.3, a new index is introduced, the token lookup index. This index is present by default in all databases created in 4.3 and later and applies to both node labels and relationship types. See Operations Manual 4.3 → Token lookup indexes for more information.

The node lookup index evolved from the label scan store, which has been present in various forms for a long time. There are many advantages of turning a label scan store into an index, but it must be noted that the node lookup index is droppable, unlike the label scan store.

The node lookup index is the most important index in the database and greatly improves the performance of Cypher queries, Core API operations as well as the population of other indexes. Dropping this index leads to severe performance degradation for most workloads. Therefore, carefully consider the consequences before doing so.

Accordingly, any index cleaning scripts that list and drop all indexes also include the node lookup index and should thus also be used with extreme caution.