You saved 4 bytes a row. Now the fix takes up to 11 hours.

transcript

Somebody saved 4 bytes a row. Picked INT over BIGINT. Now it's 2 AM, the IDs ran out, and the fix takes hours.

Option one. Change the column to BIGINT. But that's 2 billion rows. A plain alter blocks writes the whole time. Even an online tool takes hours. Option two. Leave the old table. Send new events to a new BIGINT table. Zero downtime. But every write and report now spans two tables.

How long does BIGINT take? 2 to 4 hours of testing and planning. 2 to 6 hours to copy the table online. An hour to verify. 5 to 11 hours in all. The split? Weeks to finish.

So which one? Orders, user actions, anything critical? BIGINT. Rehearse it on a replica first. Analytics or logging, and you can afford the complexity? Split the table. Reset to 1 is the last resort. It costs every bit of history.

Now the trade you made. INT: 4 bytes a row. Tops out near 2 point 1 billion. BIGINT: 8 bytes. About 9 point 2 quintillion values. On modern hardware, the speed difference is negligible.

A few bytes a row are cheaper than a 2 AM migration. You pick the column type at 2 PM on a Tuesday. Someone lives with it at 2 AM.

Full breakdown in the lecture.