Data & Databases · Level 3
Keeping it healthy
Mission briefing
Mission 6-C: Mid-demo, in front of a client, the app slows to a crawl and then throws an error. Behind the scenes, a database migration was running at exactly the wrong moment. Live demos have a sense of timing.
A migration was running — a controlled, versioned change to the database's structure, like adding a column or reshaping a table. Migrations are how the schema evolves safely over time. This one just had catastrophically bad timing against a live demo.
The slowdown got worse because a query that needed an index didn't have one. An index is like a book's index — it lets the database jump straight to the rows it needs instead of scanning every page. Without it, big tables crawl.
For demos, we should've been on seed data — fake but realistic sample data made for testing and demos, kept separate from real records. And migrations are written carefully to protect data integrity: the guarantee that the data stays accurate and consistent, with no broken links or half-finished changes.
So three lessons: run migrations off-hours, make sure demo-critical screens are indexed, and demo on seed data. None of these are "design" exactly, but knowing them makes me the kind of designer engineers actually want in the planning room.
A migration during a live demo caused slowness and errors. What's the lesson for next time?