Cypher MATCH predicate in write statements (MATCH...CREATE) full-scans instead of using unique index

[tae898]

Summary

In the opencypher surface, a MATCH ... WHERE p.<prop> = <value> predicate inside a write statement (MATCH ... CREATE ...) does not use the unique index on the property — it appears to full-scan the vertex type. The same predicate in a pure read uses the index fine, and the same write expressed in SQL is ~40x faster.

Reproduce

Schema and data (100k Person vertices; also reproduced at 10k and 1M):

CREATE VERTEX TYPE Person;
CREATE PROPERTY Person.id LONG;
CREATE PROPERTY Person.name STRING;
CREATE PROPERTY Person.age INTEGER;
CREATE PROPERTY Person.city STRING;
CREATE INDEX ON Person (id) UNIQUE;
CREATE EDGE TYPE KNOWS;
CREATE PROPERTY KNOWS.since INTEGER;
-- ingest 100k Person vertices with sequential ids

Timings (p50 over 30 executions, one statement per transaction, embedded; server via HTTP shows the same shape):

statement	p50
cypher write: MATCH (p:Person) WHERE p.id = 42 CREATE (q:Person {id: 900001, name: 'w', age: 33, city: 'c'}) CREATE (p)-[:KNOWS {since: 2026}]->(q)	31.6 ms
same semantics in sqlscript: CREATE VERTEX Person SET id = 900001, ...; CREATE EDGE KNOWS FROM (SELECT FROM Person WHERE id = 42) TO (SELECT FROM Person WHERE id = 900001) SET since = 2026	0.75 ms
cypher read: MATCH (p:Person) WHERE p.id = 42 RETURN p.name	0.30 ms

Scan evidence

The cypher write latency is linear in vertex count, which matches a full scan of Person for the MATCH:

Person count	cypher write p50
10k	4.6 ms
100k	31.6 ms
1M	371 ms

The SQL write and the cypher read stay flat (index lookup) across all three sizes.

Environment

• 26.7.2-SNAPSHOT (main as of early July 2026), reproduced in embedded (JVM in-process) and server (HTTP command endpoint, language=cypher) modes
• Linux x86_64, JDK 21

Happy to provide the full benchmark harness that found this if useful.

[lvca]

Fixed on main (commit faf899b).

Cause: a write statement with two CREATE clauses (CREATE (q...) + CREATE (p)-[:KNOWS]->(q)) takes a different execution path than a plain read. On that path the leading MATCH (p:Person) WHERE p.id = 42 was not using the unique index, so it scanned the whole Person type - which is why the time grew with the number of vertices.

Fix: the leading MATCH ... WHERE <prop> = <value> now uses the index on that path too, for both literal values (= 42) and parameters (= $id). The write is now index-backed and no longer scales with vertex count. This also covers other write shapes (MERGE, multiple CREATE, etc.), not just this exact query.

A regression test is included. Thanks for the clear report and benchmark numbers - they made this easy to pin down.

Follow-up #5136 tracks a further internal cleanup; no action needed from users.

[tae898]

Verified on our side — rebuilt from main @ faf899b and reran the same benchmark.

The cypher write is now at parity with the SQL-equivalent write (p50 6.2 ms vs 7.8 ms in that run's environment) instead of ~40x slower in a back-to-back control on the pre-fix build (197.8 ms vs 4.5 ms). That parity is exactly what an index-backed MATCH should look like: both paths are commit-dominated now.

(Absolute numbers between the two runs aren't comparable — the box shifted power states between them — but the within-run write/SQL ratio is the signal, and it went from ~44x to ~1x. We'll have clean controlled numbers in our benchmark campaign after 26.7.2.)

Thanks for the same-day fix!