A database schema shared by several application versions often cannot be changed atomically with all of its clients.

An expand-and-contract migration keeps intermediate states compatible.

A typical sequence is:

1. expand the schema by adding the new representation without removing the old one;
2. deploy code that can operate during the transition, writing or reading the representations required for compatibility;
3. migrate existing data if necessary;
4. move all consumers to the new representation;
5. contract by removing the old representation only after nothing depends on it.

For example, renaming a populated column can be implemented by adding the new column first, transitioning application reads and writes, backfilling old rows, then later removing the original column.

The temporary duplication costs complexity, but it avoids requiring every process and database change to switch at exactly one instant.

Online schema evolution is therefore an interface-compatibility problem as well as a database-migration problem.