cancel
Showing results for 
Search instead for 
Did you mean: 

Query against Node ID vs Indexed Unique Key

ferdz_steenkamp
Node Link

I'm busy developing an API that needs standard Authentication/Authorization. My users would be identified by their email (as a unique key on the User node). Which approach would be better?

  1. Index the user emails and query the user via their email on every call OR
  2. Query the user once against their email, save the node ID client side, and use the ID for remaining queries.

Note: my question has nothing to do with authentication and authorization. Simply around best practice for repetitive queries. In other words: is a query against a node id faster than a query against an indexed field on a node?

The performance concern comes in that this query would have to run for virtually every api request.

1 ACCEPTED SOLUTION

Lookup via node id is faster than an index lookup.

Be aware that if user nodes can be deleted, then you might not want to use ids, as ids of delete nodes can be reused when creating new nodes, so if you get an id, the node gets deleted, and any other node is created, that id might be reused (and it doesn't have to be a :User node), and now your query is pointing at some completely unexpected node in your graph. If queries using the id are in very close proximity to the query which looks up the id, then you may be fine. You do not want this to cache ids for longer term usage, such as saving them in some alternate database or a longer lived data structure for later querying.

View solution in original post

2 REPLIES 2

Lookup via node id is faster than an index lookup.

Be aware that if user nodes can be deleted, then you might not want to use ids, as ids of delete nodes can be reused when creating new nodes, so if you get an id, the node gets deleted, and any other node is created, that id might be reused (and it doesn't have to be a :User node), and now your query is pointing at some completely unexpected node in your graph. If queries using the id are in very close proximity to the query which looks up the id, then you may be fine. You do not want this to cache ids for longer term usage, such as saving them in some alternate database or a longer lived data structure for later querying.

Appreciated thanks

Nodes 2022
Nodes
NODES 2022, Neo4j Online Education Summit

On November 16 and 17 for 24 hours across all timezones, you’ll learn about best practices for beginners and experts alike.