Neo4j Index Selection Guide

Learn how to match Neo4j index types to query patterns and integrity needs, avoid unnecessary scans, and validate choices with PROFILE and constraint tests.

The Scan Problem

When a query on a label returns a NodeByLabelScan operator in PROFILE, the database reads every node of that label to apply filters. This linear scan becomes a bottleneck as data grows. The useful takeaway is to pick an index type that turns the scan into an IndexSeek while satisfying any integrity rules.

Decision Constraints

First, identify the query pattern:

Equality or range filters on a single property → consider a Range Index.
Need to guarantee a property value is unique per label → a Unique Constraint (creates an underlying index).
Filters that combine two or more properties on the same label → a Composite Index.
Keyword or fuzzy search inside string properties → a Full‑text Index.
Geospatial distance or radius queries → a Point Index.

Comparison Table

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Index Type	Primary Use Case	Integrity Enforcement	Search Capability
Range Index	Equality and range filters	No	Exact match, >, <, >=, <=
Unique Constraint	Entity identification	Yes (prevents duplicates)	Exact match
Composite Index	Multi‑property filtering	No (unless using a composite constraint)	Combined property matches
Full‑text Index	Keyword/Fuzzy search	No	Lucene‑based text search
Point Index	Geospatial queries	No	Distance and radius

Engineering Trade‑offs

Write Latency vs. Read Speed

Each index adds synchronous maintenance cost to CREATE and SET operations. Heavy write workloads on a labeled node can see increased lock contention or transaction timeouts if many indexes exist.

Native Store vs. Lucene

Range, Composite, and Point indexes live inside Neo4j's native store. Full‑text indexes rely on an integrated Lucene engine, making them suitable for textual search but not for simple equality filtering.

Composite Index Specifics

A composite index on (:User {firstName, lastName}) is only used when the query filters by both properties or by the first property in the index definition. Queries that filter only by lastName will not benefit and may still scan.

Implementation and Validation

Assume a Product label where:

The sku property must be unique.
Users frequently filter products by price range.

Step 1: Apply Constraint and Index

Run these statements in Neo4j Browser or cypher-shell. You need ADMIN or WRITE permission.

// Ensure SKU uniqueness (creates an underlying index automatically)\nCREATE CONSTRAINT product_sku_unique IF NOT EXISTS\nFOR (p:Product) REQUIRE p.sku IS UNIQUE;\n\n// Create a range index for price filtering\nCREATE INDEX product_price_range IF NOT EXISTS\nFOR (p:Product) ON (p.price);\n

Step 2: Verify Execution Plan

Prefix a representative query with PROFILE to see the actual database hits.

PROFILE\nMATCH (p:Product)\nWHERE p.price > 100 AND p.price < 500\nRETURN p;\n

Look for an IndexSeek or IndexScan operator on the price index. If the plan shows NodeByLabelScan followed by a Filter, the index is not being used.

Step 3: Validate Integrity

Confirm that the unique constraint blocks duplicate SKUs.

// First insertion\nCREATE (:Product {sku: 'ABC-123', price: 10});\n\n// Second insertion – should fail\nCREATE (:Product {sku: 'ABC-123', price: 20});\n

The second transaction must be rejected with a ConstraintValidationFailed error.

Limitations and Maintenance

Memory pressure: Indexes reside in the page cache; if the total index size exceeds available RAM, disk I/O increases.
Version note: Composite constraints (uniqueness across multiple properties) are available in Neo4j 4.4 and later; earlier versions only support single-property constraints.
Full‑text latency: Full‑text indexes may lag slightly behind native indexes during intense write bursts because they are updated asynchronously in some versions.

Rollback Procedure

If an index proves too costly for write performance, remove it with the following commands:

DROP CONSTRAINT product_sku_unique IF EXISTS;\nDROP INDEX product_price_range IF EXISTS;\n

Selecting Neo4j Index Types for Performance and Integrity