UUID Versions Explained — When to Use v4 vs v7
Your database needs unique IDs across distributed services that never coordinate. Auto-increment won't work. You need UUIDs — but which version?
There are five UUID versions in common use, and they solve different problems. Picking the wrong one can leak hardware addresses, fragment your database indexes, or produce collisions where you expected uniqueness. This guide breaks down every version so you can choose with confidence.
UUID versions compared
This table is the quick reference. Details on each version follow below.
| Version | How generated | Sortable | When to use | Collision risk |
|---|---|---|---|---|
| v1 | MAC address + timestamp | Yes (by time) | Legacy systems needing time ordering | Low, but leaks MAC address |
| v3 | MD5 hash of namespace + name | No | Deterministic IDs from names (legacy) | None (deterministic) |
| v4 | Random (122 random bits) | No | General purpose, most common | ~1 in 2.7 quintillion per pair |
| v5 | SHA-1 hash of namespace + name | No | Deterministic IDs (preferred over v3) | None (deterministic) |
| v7 | Unix timestamp (ms) + random | Yes (by time) | New systems needing sortable IDs | Very low |
v1: timestamp + MAC address
Version 1 UUIDs embed the current timestamp and the generating machine's MAC address. This makes them naturally sortable by creation time, which was useful for certain legacy databases. The downside is that the MAC address is encoded right in the UUID, which means anyone who reads the ID can identify the hardware that created it. For internal systems behind a firewall this may not matter, but for public-facing IDs it's an unnecessary information leak. v1 has largely been superseded by v7, which provides the same time-sortability without exposing hardware details.
v3 and v5: deterministic, name-based
Versions 3 and 5 are deterministic: given the same namespace and name, they always produce the same UUID. v3 uses MD5 internally; v5 uses SHA-1. In practice, prefer v5 over v3 because SHA-1 is a stronger hash function (though neither is used here for cryptographic security — it's about reducing collision probability in the hash output).
Use name-based UUIDs when you need a stable, reproducible identifier derived from a human-readable string. For example, you might generate a v5 UUID from a URL so that the same URL always maps to the same UUID across different systems, without those systems needing to coordinate or share a database. This is useful for deduplication, content addressing, and idempotent API designs.
v4: random
Version 4 is the workhorse. It's 122 bits of randomness (the remaining 6 bits encode the version and variant), which means the probability of two randomly generated v4 UUIDs colliding is astronomically small. You'd need to generate about 2.7 quintillion UUIDs before you hit a 50% chance of a single collision. For virtually all practical purposes, v4 UUIDs are unique.
The trade-off is that v4 UUIDs are not sortable. If you insert them as primary keys in a B-tree-indexed database (which includes most relational databases), each new insert lands at a random position in the index. This causes page splits and fragmentation over time, which degrades write performance on large tables. For small-to-medium tables this is negligible; for tables with hundreds of millions of rows, it can matter.
v7: timestamp + random (the modern choice)
Version 7 is the newest addition, defined in RFC 9562. It embeds a Unix timestamp in milliseconds in the most significant bits, followed by random data. This gives you time-sortability (newer UUIDs sort after older ones) without leaking hardware information like v1 does. Because the timestamp occupies the high-order bits, v7 UUIDs inserted into a B-tree index land roughly in order, avoiding the fragmentation problem that plagues v4 in write-heavy databases.
If you're starting a new project and need both uniqueness and sortability, v7 is the right default.
UUID vs. auto-increment IDs
The choice between UUIDs and auto-incrementing integers depends on your architecture. Here's how they compare.
| Feature | UUID | Auto-Increment |
|---|---|---|
| Uniqueness scope | Globally unique — no coordination needed | Unique within a single table/database |
| Database performance | v4 causes B-tree fragmentation; v7 avoids it | Sequential inserts, optimal for B-tree indexes |
| URL safety | Safe in URLs without encoding | Safe, but sequential IDs are predictable |
| Information leakage | v4/v5/v7 reveal nothing; v1 leaks MAC | Reveals row count and creation order |
| Distributed generation | Any node generates IDs independently | Requires a central counter or coordination |
| Storage size | 16 bytes (128 bits) | 4 bytes (int) or 8 bytes (bigint) |
Auto-increment is simpler and smaller. UUIDs are essential when you have multiple services, databases, or clients generating IDs independently — which is most distributed architectures. The storage overhead (16 bytes vs. 4 or 8) is real but rarely the bottleneck. The bigger concern is index fragmentation with v4, which is why v7 exists.
A common hybrid approach: use UUIDs as public-facing identifiers (API responses, URLs) and auto-increment integers as internal primary keys, with a unique index on the UUID column. This gives you the best of both worlds — fast sequential inserts and globally unique external IDs. You can Base64-encode UUIDs to shorten them in URLs if length is a concern.
Practical recommendations
- Use v4 for most cases. If you don't have a specific reason to pick another version, v4 is the safe default. It's universally supported, carries no metadata, and the collision risk is effectively zero at any realistic scale.
- Use v7 if you need time-sortable IDs. This is the right choice for database primary keys in write-heavy systems, event logs, and anything where "sort by creation time" matters. v7 is database-friendly and avoids the B-tree fragmentation problem.
- Use v5 for deterministic "this name always maps to this UUID." Content addressing, URL-to-ID mapping, deduplication. Prefer v5 over v3 — the SHA-1 hash gives better distribution.
- Avoid v1 in production. The MAC address leak is an unnecessary risk in any public-facing system. If you need time-sortable IDs, use v7 instead. The only reason to use v1 is compatibility with legacy systems that already depend on it.
For a deeper look at the tools adjacent to UUID generation — hashing, encoding, and other developer utilities — explore the rest of the ToolRack.
Built with vanilla HTML/JS. No frameworks, no backend, loads instantly.