[Bug]: Neo4j performance warnings: Cartesian product in Cypher queries during load testing #906

Activity

1. sscargal

   added the

   Bug

   issue type on Jan 7, 2026
2. sscargal

   self-assigned this

   on Jan 7, 2026
3. sscargal commented on Jan 7, 2026

   

   sscargal

   on Jan 7, 2026

   Last edited by sscargal

   ContributorAuthor

   More actions

   Based on my initial analysis, it seems highly likely that the performance warnings (Cartesian product alerts and slowdowns) observed during bulk/batch ingestion in Neo4j are connected to the delayed creation of an index on the uid property. Here’s my hypothesis with known Neo4j and graph database behavior:

   Key points:

   • The codebase uses a threshold (default 10,000 nodes) before it creates an index on uid.
   • Until that threshold is reached, Cypher queries matching nodes (e.g., MATCH (n {uid: ...})) must perform a full scan of all nodes with the label, i.e., an $O(N)$ operation.
   • When using bulk operations with many MATCH clauses and disconnected patterns, this leads to full scans for each source/target lookup prior to the CREATE, easily causing cartesian products, excessive data generation, and slow query planning.
   • As the node count grows, each new write gets slower due to the lack of index support.

   Effects:

   • The UNWIND + MATCH (source ...), (target ..) pattern produces a cartesian product warning if the two patterns are not connected by a variable in the MATCH. This is worsened if there are no indexes to efficiently look up nodes by uid.
   • Before hitting the node threshold, every write is highly inefficient; after that, index creation should rapidly improve per-write speed and reduce cartesian product risk.

   Next steps for investigation:

   1. Locate the threshold and index creation logic: Find where in the codebase the logic checks node count and creates an index on uid once >10,000 nodes exist.
   2. Review Cypher query construction: See if the pattern could be revised to connect the source/target lookups and avoid accidental cartesian products, e.g., by using a single MATCH with both nodes linked by an edge variable.
   3. Potential improvement: Consider lowering the threshold for index creation or checking if the deployment can support up-front index creation to reduce early insert cost and noisy warnings drastically.

   Suggested next steps:

   • Find the exact file and line where this threshold is enforced and how index creation is triggered
   • Research suggestions for safer bulk Cypher query patterns
4. sscargal

   closed this as completedin #917on Jan 12, 2026