---
title: ALTER CURRENT GRAPH TYPE
url: https://nexyron.tech/docs/cypher/clauses/schema-and-admin/alter-current-graph-type
description: Replace or incrementally change the type definition bound to the current graph.
---

# ALTER CURRENT GRAPH TYPE

## Generic Description

Replace or incrementally change the type definition bound to the current graph.

Simple example:

```cypher
ALTER CURRENT GRAPH TYPE ADD { (:Movie { title STRING }) }
```

## Consumer-Level Explanation

Use this when you need to tell Nexyron what kinds of nodes and edges the current graph is expected to contain, or when that graph shape needs to evolve over time.

## Conceptual Explanation

`ALTER CURRENT GRAPH TYPE` is not a data-mutation clause. It changes the graph-type contract for the currently bound graph. The parser supports three operational modes:

-   `SET { ... }`: replace the full current graph-type definition
-   `ADD { ... }`: extend the current graph type with new node or edge types
-   `DROP { ... }`: remove node or edge types from the current graph type

This matters when teams want explicit graph-shape governance rather than relying only on emergent labels and properties.

## More Detailed Explanation

The important conceptual distinction is between changing graph data and changing the graph's declared type shape.

Examples of where this matters:

-   a platform adds a new node type such as `:Movie` or `:Policy`
-   a relationship type gains enough importance to become part of the formal graph contract
-   a migration removes a legacy edge type that should no longer appear in the graph

The parser maps `SET` to a replace-style graph-type creation for the current graph, while `ADD` and `DROP` become explicit graph-type alterations.

## Advanced Example

This example keeps `ALTER CURRENT GRAPH TYPE` as the focal statement while showing the kind of system where graph, time, document-style metadata, and vector features coexist around the same graph contract.

```cypher
ALTER CURRENT GRAPH TYPE ADD {
  (:Incident {
    title STRING NOT NULL,
    severity STRING,
    metadata MAP,
    embedding LIST
  }),
  (:Service)-[:IMPACTS { ts DATETIME, payload MAP }]->(:Incident)
}
```

After a change like this, teams can issue queries that combine:

-   graph traversal from `Service` to `Incident`
-   event-time filtering on `IMPACTS.ts`
-   document-style inspection of `payload` or `metadata`
-   vector similarity against `embedding`

## Real Use Cases

-   Formalizing new domain entities as a product expands into new graph-driven features.
-   Tightening graph governance for regulated or multi-team environments where implicit schema drift is risky.
-   Removing obsolete types during a controlled migration instead of letting old shapes linger indefinitely.

## Real Limitations And Tradeoffs

-   A declared graph type does not automatically rewrite existing data to match the new shape.
-   Overly rigid graph typing can slow down exploratory modeling if teams are still learning the domain.
-   Replacing the entire graph type with `SET` is more disruptive than a narrowly scoped `ADD` or `DROP`.