Composite Constraints

Define multi-property constraints in Graph DB mode. Create composite unique keys, compound indexes, existence constraints, and node keys for Neo4j schema design.

February 5, 2026

Composite constraints combine multiple properties into a single constraint. In Graph DB mode, you can define constraints that span two or more properties, enabling composite unique keys, compound indexes, and node keys for Neo4j deployment.

Constraint Types

Four types of composite constraints are supported:

Type	Purpose	Neo4j Equivalent
unique	Combined properties must be unique across all nodes	CREATE CONSTRAINT ... IS UNIQUE
index	Compound index for query performance	CREATE INDEX ... FOR (n:Label) ON (n.prop1, n.prop2)
exists	All specified properties must exist (not null)	CREATE CONSTRAINT ... IS NOT NULL (multiple)
node-key	Combined unique + existence (Neo4j Enterprise)	CREATE CONSTRAINT ... IS NODE KEY

Use Cases

Composite Business Keys

OrderLine uniqueness by orderId + productId

Compound Indexes

Index on (lastName, firstName) for efficient name searches

Multi-Column Existence

Require both startDate and endDate on temporal nodes

Natural Keys

Node key on (tenantId, entityCode) for multi-tenant data

Creating Composite Constraints

Constraint Configuration

Storage Format

Composite constraints are stored at the document level:

{
  "compositeConstraints": [
    {
      "id": "constraint-001",
      "name": "orderline_pk",
      "type": "node-key",
      "nodeId": "node-orderline",
      "propertyIds": ["prop-orderid", "prop-productid"],
      "description": "Composite primary key for order lines"
    },
    {
      "id": "constraint-002",
      "name": "customer_name_idx",
      "type": "index",
      "nodeId": "node-customer",
      "propertyIds": ["prop-lastname", "prop-firstname"],
      "description": "Compound index for name searches"
    }
  ]
}

Cypher Export

Composite constraints are included in Cypher export:

// Node key constraint (Neo4j Enterprise)
CREATE CONSTRAINT orderline_pk IF NOT EXISTS
FOR (n:OrderLine)
REQUIRE (n.orderId, n.productId) IS NODE KEY;

// Composite unique constraint
CREATE CONSTRAINT tenant_entity_unique IF NOT EXISTS
FOR (n:Entity)
REQUIRE (n.tenantId, n.entityCode) IS UNIQUE;

// Compound index
CREATE INDEX customer_name_idx IF NOT EXISTS
FOR (n:Customer)
ON (n.lastName, n.firstName);

Validation

The validation service checks composite constraints:

Check	Severity	Description
Missing properties	Error	Referenced property IDs must exist on the node
Duplicate constraint	Warning	Same properties already have a constraint
Single property	Info	Use single-property constraint instead
Naming convention	Info	Constraint name should follow conventions

Property vs Composite Constraints

Choose the right constraint level:

Scenario	Use
Single column uniqueness (e.g., email)	Property-level unique constraint
Single column not null	Property-level required constraint
Multi-column uniqueness (e.g., tenant + code)	Composite unique constraint
Multi-column index for queries	Composite index
Multi-column primary key	Composite node-key

Examples

Multi-Tenant Entity

An entity that is unique within a tenant but can have the same code across tenants:

{
  "name": "tenant_entity_unique",
  "type": "unique",
  "propertyIds": ["tenantId", "entityCode"]
}

Time-Range Validation

Verify that temporal nodes always have both start and end dates:

{
  "name": "period_dates_exist",
  "type": "exists",
  "propertyIds": ["startDate", "endDate"]
}

Order Line Key

Composite primary key for line items:

{
  "name": "orderline_pk",
  "type": "node-key",
  "propertyIds": ["orderId", "lineNumber"]
}