CREATE CONSTRAINT

Generic Description

Create a schema-level correctness rule such as uniqueness or not-null.

Simple example:

CREATE CONSTRAINT uniq_email FOR (p:Person) REQUIRE p.email IS UNIQUE

Consumer-Level Explanation

Use CREATE CONSTRAINT when the query must create a schema-level correctness rule such as uniqueness or not-null 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

CREATE CONSTRAINT is about protecting data quality, not performance. It is one of the clearest ways to encode what the graph must guarantee rather than merely what queries hope is true.

What this clause is really for:

• it defines one concrete stage in the Cypher row pipeline, so variables available before and after CREATE CONSTRAINT 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 CREATE CONSTRAINT inside a complete query pipeline so the clause boundary, visible variables, and returned row shape are clear to planner tooling.

SHOW INDEXES

Real Use Cases

• enforcing business identity keys
• preventing nulls on required fields
• documenting core domain invariants

Real Limitations And Tradeoffs

• constraints can turn latent data-quality problems into explicit failures
• migration order matters when backfilling legacy data
• they should reflect durable domain rules, not temporary convenience