<aside> 📌

This is sourced from: https://planetscale.com/blog/the-problem-with-using-a-uuid-primary-key-in-mysql#best-ways-to-use-a-uuid-primary-key-with-mysql

Their ENG blog is just and action movie and it’s insanely valuable.

Go check it out!

</aside>

Have you ever wondered if using UUIDs for your database keys is a smart move… or a hidden performance trap?

If you're running distributed systems, you can’t avoid thinking about ID design.

They guarantee uniqueness across systems.

Perfect for distributed apps, right?

Well… not so fast.

The Hidden Problem

Using UUIDs as primary keys in MySQL can slow down inserts, consume more disk space, and disrupt indexing.

Here’s why:

• UUIDs are random (especially v4), which means they don’t follow the natural order MySQL expects.
• This randomness breaks MySQL’s indexing strategy (which relies on order), causing page splits and slowing inserts.
• And they’re huge. A UUID stored as a string (CHAR(36)) can take up to 9x more space than an auto-incremented integer.

What's Really Going On Behind the Scenes?