In a streaming analytics system, schema changes are particularly hard. Producers may still be sending the old shape while consumers expect the new one, materialized views built on the old columns have to be rebuilt or aliased, and the table itself may be too large to ALTER in place. The naive answer (stop writes, migrate, restart) is rarely acceptable.

Workable schema evolution treats the change as a first-class operation: add the new column or table next to the old one, dual-write or backfill, switch consumers, then retire the old shape once nothing depends on it. The process is mechanical but tedious, which is why most data platforms either avoid the problem (rigid schemas) or absorb the cost (lengthy migrations).

Tinybird treats schema changes as deployable units that run through branches and CI, so a schema evolution is a code review, not an outage.