DROP CONSTRAINT

Generic Description

Remove a named constraint.

Simple example:

DROP CONSTRAINT uniq_email

Consumer-Level Explanation

Use DROP CONSTRAINT when the query must remove a named constraint 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

DROP CONSTRAINT is usually a migration or policy-change tool. It should be used deliberately because it changes the correctness envelope of the database.

What this clause is really for:

• it defines one concrete stage in the Cypher row pipeline, so variables available before and after DROP 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 DROP 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

• retiring obsolete invariants
• constraint strategy migration
• transition periods between schema versions

Real Limitations And Tradeoffs

• removing a constraint removes a protection, not only a metadata record
• application assumptions may still depend on the old invariant
• clean-up should be coordinated with upstream writers