schema-evolution-migrator

Schema Evolution Migrator

Overview

A knowledge graph in production is not a static artifact. New data arrives continuously, schemas evolve, and nodes accumulate that no longer represent current reality. Without deliberate lifecycle management the graph grows stale, queries slow down, and the agent's reasoning degrades — not because the agent changed but because the knowledge it depends on did.

Graph databases have no ALTER TABLE, and the schema-optional nature of property graphs means schema drift happens silently. This skill packages the four operational concerns from the chapter:

• Schema evolution — Neo4j-Migrations (Flyway/Liquibase for graphs); the migration history is itself a subgraph. Every change must be N-1 compatible: the previous application version keeps working until it is replaced (Example 8-7).
• Lifecycle — append-only with TTL (CrowdStrike's Threat Graph never updates, only adds: 40+ PB, trillions of events/day, 70M req/s) and temporal invalidation (Graphiti/Zep bitemporal: invalidate the old edge, do not delete it, so historical queries still traverse it — Example 8-8).
• Incremental updates — LightRAG-style MERGE ON CREATE / ON MATCH; update cost is proportional to the new data, not the whole graph, so a deployment event is reflected within seconds instead of a nightly rebuild (Example 8-9).
• Deployment — a staged rollout coordinating three independently versioned components (schema, data, agent code) with depends_on ordering and a canary gate (Example 8-10).

When to Use

• A production graph needs a schema change (new relationship type, new constraint) deployed alongside agent-code changes.
• A dependency changed and you must record the new fact without losing the old one for causal reasoning.
• Snapshot nodes are accumulating and you need a retention policy.
• You are coordinating a release across graph schema, data backfill, and agent code and want a manifest that enforces the ordering.