Reject an incompatible schema at registration, not at consumption

unmeasured/cost to adopt: low/active

Enforcing a declared compatibility mode when a schema version is registered moves a producer-consumer break from the moment of consumption, distributed across every downstream reader, to the moment of change, localised to one author.

The same move as expand-and-contract, applied to a message topic instead of a table, and with the check mechanised.

Two limits are stated plainly in the mechanism’s own documentation and are worth carrying over. It verifies structure, not semantics: a field that keeps its type and reverses its meaning passes. And it coordinates nothing about deployment order, so a registered-compatible change can still break a rollout if producers and consumers move in the wrong sequence.

Treat it as the cheap half of the problem. It removes the class of break a machine can see, which leaves you arguing only about the ones it cannot.

The decoy

Pairwise compatibility with the previous version. A chain of changes that are each compatible with their immediate predecessor can be jointly incompatible with a consumer two versions back — which is why transitive modes exist and why the non-transitive default is the one that bites.

Evidence

Schema Evolution and Compatibility — IVDefines backward, forward and full compatibility modes, plus transitive variants that check against all prior versions rather than only the last, enforced when a schema version is registered — blocking a change that would break the declared contract with existing producers or consumers. Transitive modes exist specifically to prevent a chain of pairwise-compatible changes that are jointly incompatible.

What would settle it

How often incompatible-schema incidents actually occur, and what share registration-time enforcement prevents. The mechanism is documented only by its vendor and no adoption or effectiveness numbers appear to have been published by anyone.

Last reviewed 2026-08-19.