Schema Evolution — ELI5

Imagine you live in a house and decide to add a new room. You cannot just tear down a wall while everyone is sleeping — you need a plan. You build the new room first, make sure the plumbing and electricity connect properly, then gradually move things over. At no point should the house become unlivable.

Schema evolution is the same idea for data in software. A “schema” is the blueprint of what your data looks like — what fields exist, what types they are, and how they relate to each other. When your application grows and needs to store new information or change how existing information is organized, you need to update that blueprint.

The tricky part: old data still exists. A database might have millions of records in the old format. Other programs might still expect the old shape. Users might be running older versions of your app. You cannot just flip a switch and change everything at once.

Schema evolution is the set of techniques for changing your data blueprint gradually and safely. You add new fields with sensible defaults so old data still works. You keep old fields around temporarily while new code learns to use the new ones. You write migration scripts that transform old records into the new format, one batch at a time.

The goal is never breaking anything during the transition. Old and new code coexist, old and new data coexist, and eventually you clean up the old stuff once nothing depends on it anymore.

One thing to remember: Schema evolution is how you change the shape of your data without breaking the systems that already depend on it — like renovating a house without making it unlivable.