SET

Generic Description

Mutate properties or labels on bound entities.

Simple example:

MATCH (p:Person {name: 'Alix'}) SET p.last_seen = datetime('2025-01-02T10:00:00Z')

Consumer-Level Explanation

Use SET when the query must mutate properties or labels on bound entities and the planner needs to see that operation as part of the Cypher row pipeline. Keep the clause explicit because it controls row grain, variable scope, and what later clauses are allowed to reference.

More Detailed Explanation

SET is the main enrichment and update clause. It is frequently used to stamp temporal state, attach embeddings or metadata, normalize payloads, or materialize derived values after analysis.

What this clause is really for:

• it defines one concrete stage in the Cypher row pipeline, so variables available before and after SET must be clear
• it should make graph structure, temporal filters, document payload shaping, or procedure output explicit instead of relying on client-side interpretation
• planner tooling depends on this clause boundary to know row grain, variable scope, and whether later expressions are reads, writes, schema operations, or projections

Advanced Example

This example keeps SET inside a complete query pipeline so the clause boundary, visible variables, and returned row shape are clear to planner tooling.

UNWIND [{user_id: 'u-1', doc_id: 'd-1', ts: '2025-01-02T10:00:00Z', payload: {kind: 'view'}, doc_metadata: {kind: 'report'}, embedding: [0.22, 0.18, 0.44]}] AS evt
MERGE (u:User {user_id: evt.user_id})
MERGE (d:Document {doc_id: evt.doc_id})
CREATE (u)-[e:VIEWED]->(d)
SET e.ts = toDateTime(evt.ts),
    e.payload = evt.payload,
    d.metadata = evt.doc_metadata,
    d.embedding = vector(evt.embedding)
WITH u, d, e, date_trunc('day', e.ts) AS day_bucket
RETURN u.user_id, d.doc_id, day_bucket, keys(properties(d)) AS doc_keys

Real Use Cases

• event-time stamping
• derived-score materialization
• schema evolution through property backfills

Real Limitations And Tradeoffs

• blind SET can overwrite useful existing state
• large update sets can be operationally heavy
• you need to understand whether you are mutating nodes or relationships