A captured table gains a nullable column; what do Debezium's Avro consumers and the schema registry see?

## The chain of events An `ALTER TABLE ... ADD COLUMN` in the source produces four visible effects, in order. First, the connector observes the DDL — from the binlog for MySQL, from refreshed relation metadata for Postgres — and updates its in-memory table model. Second, if schema-change publishing is enabled, a DDL change event is written to the schema change topic named after the connector's `topic.prefix`; this is the feed a downstream system watches to auto-evolve a target table or to raise an alert. Third, the next row change from that table is serialised against a new value schema containing the new field. Fourth, with a registry-backed converter, that schema is registered under the topic's subject, becoming a new version. ## Why adding a nullable column is the easy case Debezium maps a nullable source column to an optional field whose default is null. In Avro terms the new field is a union with null and it has a default, which is precisely the condition under which a reader using the *old* schema can still read data written with the new one, and a reader using the new schema can read *old* data by filling in the default. That is why teams get away with additive schema changes for years without touching consumers: the new field is simply invisible to anyone who has not redeployed. Note that both the `before` and `after` structs gain the field if you publish the full envelope, and that snapshot events use the same schema as streamed ones. If you have flattened events, the row schema gains the field directly. ## Where it breaks **Dropping a column.** Consumers that require the field can no longer read new records, and under a backward-compatibility rule the registry refuses the new schema. The connector task fails and capture for that table stops — this is the outage, and it is caused by a source-side migration that nobody told the data team about. **Changing a type.** Widening an integer or lengthening a varchar is often tolerable; changing an integer column to text, or a timestamp's precision, generally is not, and Debezium's temporal and decimal handling adds its own wrinkles because the wire representation depends on connector settings. **Renaming.** A rename is a drop plus an add as far as the schema is concerned, with the extra insult that the data moves silently into a field nobody is reading. **Non-nullable additions.** A `NOT NULL` column with no default has no safe default in the emitted schema, so old readers have nothing to fall back on. **Illegal names.** Avro's naming rules are stricter than SQL's. A table or column whose name is legal in the database but not in Avro must be adjusted, which Debezium handles through a name-adjustment mode; leaving it unset and then hitting such a name is a startup-time surprise rather than a runtime one. ## Failure shape and blast radius The failure is not a dropped record. It is a failed task: capture for the table stops, lag climbs, and on engines with finite log retention a long enough stall becomes a mandatory re-snapshot. That asymmetry is the argument for treating source DDL as a governed change rather than an ordinary migration. ## How mature teams run this Make additive-and-nullable the default migration shape, and require a two-phase deploy for anything else: add the new column, backfill, move consumers, then drop the old column in a later release once nothing reads it. Consume the schema change topic and alert on it, so a data team learns about a source migration when it happens rather than when the pipeline dies. Put a compatibility check in the producer team's CI so an incompatible migration fails a build instead of a connector. And decide deliberately whether you want the pipeline to *stop* on an incompatible change — which is what a strict registry rule gives you and is often the right answer for a system of record — or to keep flowing with a permissive landing schema, which is a different discipline entirely. The deepest version of this answer is the one that says the outbox pattern sidesteps most of it: when the published payload is a designed event rather than a row image, an `ALTER TABLE` on a business table changes nothing that any consumer can see, and schema evolution becomes a versioning decision made deliberately by the producing team rather than a side effect of a migration.