What Is a UUID and When Should You Use One?

Pick an ID strategy too early in a project and you rarely think about it again until it becomes a problem. Auto-incrementing integers work fine until you need to merge data from two databases, expose IDs to the public without leaking your row count, or generate an ID before the record ever touches a database. That is usually the point where UUIDs enter the conversation.

A UUID, short for Universally Unique Identifier, is a 128-bit value designed to be unique across systems without any central coordination. Two different machines, offline from each other, can each generate a UUID and the odds of a collision are so low they are generally treated as zero for practical purposes.

What a UUID Looks Like

A UUID is typically written as 32 hexadecimal digits, split into five groups by hyphens:

123e4567-e89b-12d3-a456-426614174000

That format is 8-4-4-4-12 characters. Certain digits in the string are fixed by the UUID version and variant, which is how you can tell, just by looking at a UUID, which generation algorithm produced it.

Why Not Just Use Auto-Increment Integers

Auto-incrementing integers are simple, compact, and sort naturally by insertion order, which is exactly why they remain the default in most database tutorials. But they come with real limitations in distributed and public-facing systems:

• They require a central authority. Only the database can hand out the next number, which means you cannot generate a valid ID until you have already written to the database.
• They leak information. A user ID of 4,821 tells anyone looking at it roughly how many users you have and lets them guess at IDs that do not belong to them.
• They collide across systems. Merging records from two databases that both used auto-increment IDs starting at 1 means you will hit conflicts immediately.

UUIDs solve all three: they can be generated anywhere, they reveal nothing about record count, and the probability of two independently generated UUIDs colliding is negligible enough to ignore in practice.

UUID Versions and What They Are For

Not all UUIDs are generated the same way. The version number, embedded in the UUID itself, tells you which algorithm was used.

UUID v4 vs UUID v7

Version 4 is what most people mean when they say "a UUID." It is generated from random bits, with only a few fixed bits reserved to identify it as version 4. This randomness is exactly what makes it unpredictable and safe to expose publicly, but it comes with a cost: because v4 values are random, they do not sort in any meaningful order, and inserting them as primary keys in a B-tree index causes the index pages to be written in scattered, unpredictable locations. On large tables, this fragments the index and can noticeably slow down writes.

Version 7 was designed to fix that. A UUID v7 embeds a millisecond-precision timestamp in its most significant bits, followed by random bits for uniqueness. This means UUID v7 values generated later in time sort after ones generated earlier, similar to how auto-increment IDs behave, while still being globally unique and generatable without a central authority. That combination makes v7 a strong default for new systems that want UUIDs as primary keys without paying the index fragmentation cost of v4.

When You Should Use a UUID

• Distributed systems generating IDs independently. If multiple services or offline clients each need to create a new record ID without checking in with a central database first, UUIDs let them do so safely.
• Public-facing identifiers. UUIDs in a URL or API response do not reveal how many records exist or let someone guess at adjacent IDs.
• Merging data across databases. Since UUIDs do not depend on any single database's sequence, combining records from multiple sources will not produce collisions.
• Offline-first applications. A mobile app that needs to create records before it ever reaches the server can generate a valid, permanent ID locally.

When You Should Not

• High-throughput systems where index performance matters and you cannot use v7. Random UUID v4 values as clustered primary keys degrade write performance on large tables. Either switch to v7, or use an auto-increment integer as the primary key and store the UUID as a secondary indexed column for external use.
• Storage-constrained systems. A UUID takes 16 bytes stored as binary, or 36 bytes stored as a string with hyphens, versus 4 or 8 bytes for an integer. At small scale this does not matter. At billions of rows across multiple indexes, it does.
• When human readability matters. Support tickets, order numbers, and anything a person needs to read aloud or type manually are usually better served by a short, readable identifier than a 36-character UUID.

A Practical Middle Ground

A common pattern in production systems is to use both: an internal auto-increment or UUID v7 primary key for fast, ordered database operations, plus a separate UUID v4 exposed externally in the API for anything public-facing. This gets you fast writes internally and unguessable, non-leaking identifiers externally, without forcing a single ID strategy to do both jobs at once.

Generate and Validate UUIDs Instantly

Generate UUID v4 or v7 values, validate existing UUIDs, and inspect their structure with the free Yurlie UUID Tool.