Schema evolution is how a table's structure changes over time: new columns, widened types, renamed or removed fields. Table formats such as Delta Lake and Apache Iceberg can apply some changes automatically, but unplanned drift, such as a number arriving as text, can silently turn values into nulls.
For example, a supplier adds a discount_code column to its daily orders file and, in the same week, starts sending quantities as text instead of numbers. The new column is harmless if the pipeline adds it to the bronze table as a column that may be null. The type change is not: a strict load fails, which is noisy but safe, while a lenient load may cast every quantity to null, which is quiet and wrong. A good pipeline treats the two changes differently.
Table formats offer controls for this. Delta Lake enforces the table's schema on write and adds new columns only when a write explicitly allows it; Iceberg tracks columns by id, so renames and reorders are safe for old files. Widening a type, such as a smaller integer to a larger one, is usually allowed, while narrowing it or changing a number to text needs a rewrite. Removing a column breaks every reader that still selects it.
The practical rule is to decide per kind of change what happens: add new columns automatically in bronze, fail on type changes in key columns, quarantine rows that cannot be cast, and alert someone in each case. Downstream, silver and gold tables should change only on purpose, through reviewed code. See also data quality test and lineage.
Source systems change without notice more often than anyone plans for, so the cheapest protection is to detect change early: compare each file's columns and types with the table's before loading, and report the difference in a form a person can read. See also data contract and Apache Iceberg.
Emolysis's Ingest (batch) and Dedupe / conform shapes detect drift and either cast, quarantine or fail, as the template's slots specify. A data contract makes the expected shape explicit.