Why Google Doesn't Use UUIDs Everywhere

When building your first application, using a UUID for every record feels like the obvious choice.

They're globally unique, impossible to guess, and don't require a central database.

UUID id = UUID.randomUUID();

Problem solved... right?

Not quite.

At large scale, UUIDs can actually make your database slower.

The Hidden Problem

Most SQL databases store records using a B-Tree index.

Ideally, every new row gets inserted at the end of the tree.

1
2
3
4
5
6
7

Auto-increment IDs behave exactly like this.

1
2
3
4
5

Every insert is sequential.

Now imagine inserting random UUIDs.

9af2...
13bc...
72dd...
01aa...
f81c...

Every insert could land anywhere inside the index.

The database constantly splits pages, reorganizes nodes, and rewrites data.

This is called index fragmentation.

As your table grows to millions of rows, inserts become noticeably slower.

Enter Snowflake IDs

Companies like Twitter introduced Snowflake IDs.

Instead of random numbers, every ID contains useful information.

| Timestamp | Machine ID | Sequence |

A typical Snowflake ID is a 64-bit integer.

195637281002398721

Since IDs are generated in timestamp order, they are almost always increasing.

That means inserts happen at the end of the index.

The database stays fast.

Why Not Just Auto Increment?

Auto-increment works well...

Until you have multiple servers.

Server A
 
Next ID = 101
 
-----------------
 
Server B
 
Next ID = 101

Now both servers generate the same ID.

Snowflake solves this by embedding a Machine ID.

Timestamp
      |
Machine ID
      |
Sequence Number

Every server can generate unique IDs independently without talking to a central database.

A Simple Snowflake Layout

64 Bits
 
41 bits  Timestamp
10 bits  Machine ID
12 bits  Sequence

The timestamp keeps IDs ordered.

The machine ID prevents collisions.

The sequence allows thousands of IDs to be generated within the same millisecond.

Which One Should You Use?

| ID Type | Best For | |----------|----------| | Auto Increment | Small applications with a single database | | UUID | Public identifiers, APIs, security | | Snowflake | Large distributed systems |

Many production systems actually use both.

An internal numeric ID keeps database indexes efficient, while a UUID is exposed publicly through APIs.

Final Thoughts

UUIDs are excellent at guaranteeing uniqueness, but uniqueness isn't the only thing that matters.

At scale, databases care just as much about how data is inserted as what data is inserted.

That's why many distributed systems generate ordered IDs like Snowflake instead of relying solely on random UUIDs.

Sometimes, the fastest database optimization isn't adding more hardware. It's choosing a smarter primary key.