Great question—this is a common point of confusion when switching between relational databases and Neo4j, so let’s break it down clearly.

1. Is MERGE (with ON CREATE) equivalent to SQL's INSERT...ON DUPLICATE KEY? #

In the scenario you described—using MERGE paired with ON CREATE (and no ON MATCH logic)—the behavior is extremely similar to SQL’s INSERT...ON DUPLICATE KEY UPDATE, but there are critical nuances to understand:

Side-by-Side Example #

Let’s map your exact statements:

• Cypher:

  MERGE (a:Person {name: "Ann"}) ON CREATE SET a.twitter = "@ann"
  

• SQL (assuming name is a unique constraint on the Person table):

  INSERT INTO Person (name) VALUES ("Ann") ON DUPLICATE KEY SET twitter = "@ann"
  

Both do the same core logic:

• If the record (node in Cypher, row in SQL) doesn’t exist (matched by name), create it and set the twitter attribute.
• If the record already exists, leave it untouched (since we’re only using ON CREATE, not ON MATCH).

Key Differences #

The biggest distinction is how uniqueness is enforced:

• In SQL, ON DUPLICATE KEY depends on a predefined unique constraint (primary key or unique index) on the column(s) you’re using to check for duplicates.
• In Cypher, MERGE checks for existing nodes that match all properties in the MERGE clause plus the label(s). For it to behave reliably like INSERT...ON DUPLICATE KEY, you must define a unique constraint on Person(name) in Neo4j. Without this constraint, concurrent transactions could create duplicate nodes (since there’s no atomic check-and-create guarantee).

2. Does MERGE act like CREATE when the target node doesn't exist? #

Absolutely! When the node (or relationship—MERGE works for both) specified in the MERGE clause isn’t present in the graph, MERGE behaves exactly like CREATE. It will create the node with the specified label(s) and properties, then run any ON CREATE clauses to set additional attributes.

For example, if no Person node with name: "Ann" exists, your MERGE statement will create that node just as CREATE (a:Person {name: "Ann"}) would, then set a.twitter = "@ann" via the ON CREATE clause.

A quick reminder: without a unique constraint, concurrent MERGE operations on the same node can lead to duplicates. Adding the constraint locks in the atomic check-and-create behavior, just like a unique key in SQL.

内容的提问来源于stack exchange，提问作者David542