Schema Evolution
Changing a table's structure over time while keeping existing data readable and existing consumers working.
The recurring difficulty in analytical storage: data written last year has a shape, the code reading it has a different shape, and both must work.
Safe changes, in the same sense as API compatibility: adding an optional column (old files return null), widening a type (int to long), renaming where the format tracks columns by field ID rather than by name or position — which is a specific advantage of Iceberg and the reason renames are safe there and destructive in bare Parquet, where position-based resolution silently returns the wrong column's data.
Unsafe: dropping a column consumers still read, narrowing a type, changing semantics while keeping the name — the last being the most dangerous because nothing errors.
Partition evolution is the related capability worth naming: changing the partitioning scheme without rewriting history, so a table partitioned by day can move to hourly for new data while old data stays as it is. Without it, a partitioning decision made at table creation is permanent.
The governance point: schema changes to a shared analytical table affect consumers you may not know about, so the same discipline that applies to APIs — compatibility checks in CI, a registry, a deprecation policy — belongs here.