Indexes & Query Tuning

Without secondary structures, finding a person by name means scanning every Person node and filtering. That is acceptable for tiny demo graphs and disastrous for production multi-million node stores. A RANGE index on a property (for a label or relationship type) lets the planner perform seeks and range scans for equality and inequality predicates on that property. In modern Neo4j, RANGE is the default general-purpose property index type for many workloads (text, numbers, temporals), replacing older btree naming in documentation.

Creating an index is a schema operation, for example CREATE INDEX person_name IF NOT EXISTS FOR (p:Person) ON (p.name). Indexes improve read performance for matching predicates but add write overhead and storage. Index only properties you filter or join on frequently.

LOOKUP indexes (token indexes) help the database find all nodes for a label or all relationships for a type efficiently. They are not property uniqueness mechanisms. On current Neo4j versions, token lookup indexes are typically present by default; you still need property indexes for selective property access paths.

Full-text and vector indexes exist for specialized search and similarity workloads. This lesson focuses on RANGE and LOOKUP because they underpin ordinary Cypher transactional queries on the Movie graph and most OLTP application patterns.

// Property RANGE index for person name lookups
CREATE INDEX person_name IF NOT EXISTS
FOR (p:Person) ON (p.name);

// Property index for movie title
CREATE INDEX movie_title IF NOT EXISTS
FOR (m:Movie) ON (m.title);

A uniqueness constraint declares a business rule: at most one node with a given label and property value. Neo4j backs uniqueness with an index so enforcement is efficient, but the constraint is what rejects duplicates. An index alone never stops two Person nodes from sharing the same email.

Property existence and type constraints (availability depends on edition and version) further protect data quality. For application design, put uniqueness on natural keys early— external ids, emails, SKUs—so imports and concurrent writers cannot fork identity. Lesson 10 returns to this theme in modeling and drivers.

Syntax sketch: CREATE CONSTRAINT person_name_unique IF NOT EXISTS FOR (p:Person) REQUIRE p.name IS UNIQUE. Exact keywords have evolved; consult the constraints section of the Cypher Manual for your version. Always prefer IF NOT EXISTS in migration scripts.

EXPLAIN prefixes a query to show the planner’s chosen operators without running the query against data (no result rows, no write effects from the explained statement’s execution). Use it while drafting to see whether you get an index seek or a label scan.

PROFILE executes the query and annotates each operator with runtime metrics: how many rows flowed out, and how many database hits occurred. PROFILE is the truth serum for performance—“I thought this was selective” becomes “Filter discarded 2 million rows after a label scan.”

Important operators to recognize:

• NodeByLabelScan — visits all nodes with a label. Cheap on tiny graphs; costly on large ones when followed only by a Filter.
• NodeIndexSeek / NodeIndexScan — uses a property index to find candidate nodes. Seeks are ideal for equality; scans cover ranges.
• Expand(All) — walks relationships from a bound node to produce neighbors.
• Filter — applies predicates that were not pushed into an index seek.
• Eager aggregation or other eagerness boundaries — can materialize large intermediate sets; watch memory.

Tuning workflow: write correct Cypher first, PROFILE with realistic data volumes, ensure selective predicates can use indexes, reduce intermediate cardinality before expansions, and return projections instead of whole graphs. Avoid premature micro-optimization on demo data— plans change with statistics.