What Is a UUID, and When Should You Use One Instead of an Auto-Increment ID?

UUID stands for universally unique identifier. It is a 128-bit value, usually written as 32 hexadecimal characters in five hyphen-separated groups, like 550e8400-e29b-41d4-a716-446655440000. The defining property: you can generate one on any machine, at any time, with no coordination, and it will be unique in practice. That property is powerful, but it is not free, and a plain auto-increment integer is often the better choice. Here is what a UUID actually is and when to reach for one.

Last updated: June 2026

What a UUID Actually Is

A UUID is just a very large random or semi-random number, formatted in a standard way. The most common version, v4, is 122 bits of randomness (a few bits are reserved to mark the version). The space of possible v4 UUIDs is so large that the chance of two independently generated ones colliding is negligible for any realistic system.

The key idea is decentralized uniqueness. A traditional database auto-increment ID requires the database to hand out the next number, so the database is the single source of truth. A UUID can be generated by the client, a background job, or three different servers at once, and they will not collide without any of them talking to each other. You can generate a UUID in the browser this second without a server involved at all.

How Unlikely Is a Collision, Really?

This is the question that makes people nervous. The honest answer: for v4 UUIDs, you would need to generate billions of UUIDs before the probability of a single collision became worth worrying about. To get a 50 percent chance of one collision you would need to generate on the order of a quintillion UUIDs. No normal application comes anywhere near that. For practical purposes, treat v4 UUID collisions as something that does not happen. The exception is if your random number source is broken (a bad pseudo-random generator), in which case collisions become possible. Use a proper cryptographic random source, which standard libraries do by default.

UUID vs Auto-Increment Integer: The Real Tradeoff

The choice between a UUID and a sequential integer primary key is one of the more consequential schema decisions you make. Each has clear advantages.

When the auto-increment integer wins

• Storage and speed: a 4 or 8 byte integer is smaller and faster to index than a 16 byte UUID. At scale this matters.
• Insert performance: sequential integers append to the end of the index, keeping it tight. Random UUIDs scatter inserts and fragment the index (this is why UUID v7 exists, to restore ordering).
• Human friendliness: "order 1043" is easier to read, type, and discuss than a 36-character UUID.

When the UUID wins

• Decentralized generation: you need IDs created on clients, offline devices, or multiple servers without coordination.
• Merging data: combining records from multiple databases is painless when IDs are globally unique; with auto-increment integers you get collisions.
• Hiding business metrics: a sequential ID leaks information. A competitor who sees order 1043 today and 1098 next week can estimate your volume. UUIDs reveal nothing about count or sequence.
• URLs and external references: exposing a sequential ID in a URL invites enumeration (guessing /user/1, /user/2). UUIDs are not guessable, though they are still not a substitute for access control.

The Modern Compromise: UUID v7

The classic knock on UUIDs as primary keys was insert performance, because random v4 values fragment the index. UUID v7 fixes this by embedding a timestamp in the high bits, so newly generated UUIDs sort roughly by creation time and inserts stay clustered like a sequential integer. In 2026, if you want the decentralized-uniqueness benefits of a UUID without the write-performance penalty, v7 is the default to reach for. It gives you most of the integer's index behavior with the UUID's portability.

Where You Will Actually Meet UUIDs

• Database primary keys in distributed or client-generated systems.
• Correlation IDs stitching a single request across multiple services in logs.
• Idempotency keys so a retried payment or API call is not processed twice.
• File and resource names that must not collide when uploaded from many sources.
• Session and token identifiers (though these should also be backed by real auth, not the UUID alone).

Common Misconceptions

"UUIDs are secure"

A v4 UUID is unguessable, but it is an identifier, not a secret. Do not use a UUID as your only access control. Anyone who obtains the UUID can use it; protect resources with authentication, not obscurity.

"UUIDs guarantee uniqueness"

They guarantee it statistically, not absolutely, and only if your random source is sound. With a proper generator the practical guarantee is total, but a broken RNG breaks the guarantee.

"Always use UUIDs for everything"

No. For a single-database app where IDs never leave the system and you never merge data, an auto-increment integer is smaller, faster, and friendlier. Use a UUID when you have a reason: decentralization, merging, or hiding sequence.

The Bottom Line

A UUID is a large, standardized, practically-unique number you can generate anywhere without coordination. Reach for one when you need decentralized generation, painless data merging, or want to avoid leaking sequence in URLs and metrics. Stick with an auto-increment integer when none of those apply and you want the smallest, fastest, most readable key. And if you choose a UUID as a primary key in 2026, prefer v7 so you keep the integer's index behavior. When you just need one quickly, generate it in the browser.