How does Cassandra handle schema migrations in production?

Cassandra schema migrations require careful handling due to its distributed nature. Schema propagation: Cassandra schema changes propagate to all nodes via gossip — there is a brief period where some nodes have the new schema and others have the old. During this window, queries may behave inconsistently. Safe migration patterns: Add columns: safe — old clients ignore new columns; new clients can start writing them immediately. Remove columns: two-step: (1) remove all references in application code and deploy, (2) then drop the column from the schema. If you drop first, old code breaks. Table renames: not supported — create new table, migrate data, switch traffic, drop old table. Change primary key: not possible — create new table with desired schema, migrate data. Index changes: create new index, test, drop old index. Tooling: Liquibase has a Cassandra plugin. Pillar (Python) manages Cassandra migrations. Schema versioning: track schema version in a dedicated Cassandra table. Zero-downtime: blue/green deployments — deploy new schema, roll out new code that handles both old and new schema, remove backward compatibility after full rollout.