Complete Guide to UUID Versions

Quick Answer

Which UUID version should you use?

• UUIDv7 - best default for new database-backed applications
• UUIDv4 - best for broad compatibility and simple random identifiers
• UUIDv5 - use when the same namespace + name must always produce the same UUID
• UUIDv1 - primarily for legacy compatibility
• UUIDv6 - time-ordered alternative for systems based on the UUIDv1 model
• UUIDv8 - application-defined formats when you have a specific reason to customize the layout

UUID Version Summary

UUIDs (Universally Unique Identifiers) are standardized 128-bit identifiers defined by RFC 9562 (which obsoletes RFC 4122). Each UUID version was designed for different requirements, such as randomness, determinism, chronological ordering, or custom data layouts.

Although all UUIDs share the same 128-bit structure and text format, each version uses those bits differently for timestamps, randomness, hashes, node identifiers, or application-defined data. Choosing the right version matters more than it might seem: the wrong choice can leak information (like a device's MAC address or creation time), hurt database performance through fragmented indexes, or make it impossible to regenerate the same identifier deterministically when you need to. The table below is a quick-reference starting point - the sections further down explain the reasoning behind each version.

Comparison

Beyond just "which version is best," the properties in this table decide why a version fits a given job. Randomness protects against guessability and information leakage; time-basis and sortability matter almost entirely for database write performance; and determinism is what lets you compute the same UUID twice from the same input, which is essential for de-duplication and idempotent systems. Use this table to weigh trade-offs side by side before picking a version for a new system.

Structure Comparison

Every UUID version uses the 128-bit UUID structure differently. Timestamp-based versions allocate bits to time information, hash-based versions use namespace-derived values, random versions use random data, and UUIDv8 leaves much of the layout application-defined.. Timestamp-based versions trade some randomness for chronological order; hash-based versions trade randomness entirely for repeatability; and UUIDv8 gives up a standard layout altogether in exchange for total flexibility. Understanding what data actually goes into a UUID helps explain why, for example, UUIDv1 can leak hardware information while UUIDv4 can't.

When to Use Each Version

The "right" UUID version depends less on the technology and more on what your system actually needs from its identifiers. If you just need a unique value with no other requirements, UUIDv4 is the safe default almost everyone reaches for. If those identifiers are also primary keys in a high-write database, the sort-order versions (UUIDv7, or UUIDv6 where broader compatibility is needed) will noticeably reduce index fragmentation. And if you need to derive the same identifier repeatedly from the same input - say, generating a stable ID for a URL or email address - only the deterministic hash-based versions (UUIDv3/UUIDv5) will do that.

UUIDv1

UUIDv1 combines a timestamp with a node identifier, historically a MAC address. It was one of the four original versions defined back in RFC 4122 and remains common in older enterprise systems, directory services, and infrastructure that predates the newer time-ordered versions. Because the timestamp and node ID are baked directly into the identifier, a UUIDv1 value can be parsed back to reveal roughly when - and sometimes on which machine - it was generated, which is a meaningful privacy trade-off for public-facing systems.

Advantages

• Chronologically ordered
• Very low collision probability
• Supported by many older systems

Disadvantages

• Can reveal creation time
• May expose hardware information
• Less privacy friendly

UUIDv3

UUIDv3 creates deterministic UUIDs by hashing a namespace and name using MD5. Feeding the same namespace/name pair into the algorithm will always produce the identical UUID, which makes it useful for generating stable IDs from existing values (like a domain name or file path) without needing to store a lookup table. Its main drawback is its reliance on MD5, a hashing algorithm considered cryptographically weak for security-sensitive purposes - for new deterministic UUIDs, UUIDv5 is generally the safer choice.

Advantages

• Same input always produces the same UUID
• Useful for names and identifiers

Disadvantages

• Uses MD5
• Not random

UUIDv4

UUIDv4 is generated using cryptographically secure random numbers, with no timestamp, hash, or hardware data embedded anywhere in the value. Approximately 122 bits are random, giving an astronomically low chance of collisions - in practical terms, you could generate billions of UUIDv4 values and still have a negligible chance of a duplicate. This is why it's the default choice across nearly every programming language's standard library and the most widely recognized UUID format in general use today.

Advantages

• Most widely supported
• Excellent privacy
• Extremely low collision probability
• Very easy to generate

Disadvantages

• Not sortable
• Random inserts can fragment database indexes

UUIDv5

UUIDv5 is deterministic like UUIDv3 but uses SHA-1 instead of MD5, making it the more modern and generally preferred option when you need repeatable, name-based identifiers. It's frequently used to generate consistent IDs for resources identified by a URL, DNS name, or other namespaced string, so that the same input reliably maps to the same UUID across different systems or services without any coordination needed.

Advantages

• Stable identifiers
• Uses SHA-1 instead of MD5

Disadvantages

• Not random
• Not sortable

UUIDv6

UUIDv6 rearranges the UUIDv1 timestamp fields so identifiers sort naturally in ascending order, addressing one of UUIDv1's biggest practical weaknesses. It was introduced specifically as a bridge for systems that need time-ordered identifiers but also want to stay closer to the traditional UUIDv1 field layout, rather than jumping straight to the newer UUIDv7 format. It's a solid option where infrastructure already expects UUIDv1-style structures but database sort performance still matters.

Advantages

• Better for databases
• Time ordered
• Compatible with UUID infrastructure

Disadvantages

• Less common
• Timestamp still visible

UUIDv7

UUIDv7 combines a Unix-millisecond timestamp with additional bits used for randomness, counters, or sub-millisecond timestamp information. It is designed to improve database index locality compared with randomly generated UUIDs such as UUIDv4 while preserving strong randomness where it counts. Because the timestamp sits in the most significant bits, UUIDv7 values sort naturally by creation time, which keeps B-tree indexes compact and insert performance high - a major advantage over UUIDv4 in write-heavy database workloads. This combination of ordering and randomness is why it's quickly becoming the recommended default for new applications.

Advantages

• Naturally sortable
• Database friendly
• Good privacy (Does not expose a node/MAC identifier, but does expose creation time through its 48-bit Unix-millisecond timestamp)
• Modern standard
• Fast indexing

Disadvantages

• Newer libraries may not yet support it

UUIDv8

UUIDv8 reserves the internal data layout for application-specific formats, effectively giving developers a standardized "wrapper" around a completely custom identifier scheme. This is useful when an organization already has its own internal ID format (for example, one combining a shard ID, timestamp, and sequence number) and wants that value to remain interoperable with systems and libraries expecting a valid, spec-compliant UUID.

Advantages

• Extremely flexible
• Allows custom identifier schemes

Disadvantages

• No universal internal format
• Limited interoperability

Popularity

Real-world adoption doesn't always track perfectly with technical merit - legacy systems keep older versions like UUIDv1 and UUIDv3 alive well past their prime, while UUIDv4's simplicity has made it the long-standing default even in cases where UUIDv7 would now perform better. As more databases and ORMs add native UUIDv7 support, expect that share to keep shifting toward the newer, sortable versions.

Which Version Should You Choose?

There's no single "best" UUID version - only the version that best matches your constraints. The table below maps common requirements to their strongest match, but as a general rule of thumb: default to UUIDv4 unless you have a specific reason not to, switch to UUIDv7 if your identifiers are database primary keys, and reach for UUIDv5 only when you specifically need the same input to always produce the same output.

For most new software projects, UUIDv7 is the recommended choice because it combines chronological ordering with strong randomness, making it ideal for modern databases and distributed systems. If broad compatibility is your highest priority, UUIDv4 remains an excellent option.

UUID Standards and Version History

The UUID specification has evolved over time through publications by the Internet Engineering Task Force (IETF). Two RFCs define the standardized UUID versions used today, and understanding the shift between them helps explain why newer versions like UUIDv6 and UUIDv7 exist at all - they were direct responses to real limitations engineers ran into with the original four.

RFC 4122

RFC 4122 was the original UUID standard published in 2005. It standardized four UUID versions, establishing the timestamp-based, hash-based, and random generation approaches that later versions would build on:

For nearly twenty years, these four versions formed the basis of virtually all UUID implementations, and they're still fully valid and widely supported today - RFC 9562 didn't deprecate any of them, it simply added more options on top.

RFC 9562

In 2024, RFC 9562 replaced RFC 4122. It retained the existing UUID versions while introducing new versions designed for modern applications and databases, largely in response to the widespread adoption of UUIDs as database primary keys and the performance problems that random UUIDv4 values caused for index locality.

RFC 9562 defines eight UUID versions:

The most significant additions are UUIDv6 and UUIDv7, which improve insertion performance in databases by producing identifiers that naturally sort by creation time - directly addressing one of the most common complaints developers had about using UUIDv4 as a primary key.

What About UUIDv2?

UUIDv2 was used by the Distributed Computing Environment (DCE) Security specification, an older framework for distributed computing that predates the modern UUID RFCs. Unlike the other UUID versions, it was never formally standardized by the IETF, and its intended use - embedding POSIX UID/GID values and a timestamp - never gained meaningful adoption outside of DCE environments.

RFC 9562 reserves Version 2 but does not define a generation algorithm for it. As a result, UUIDv2 is rarely implemented and is generally not recommended for new software; if you encounter a "version 2" identifier in the wild, it's most likely a legacy or vendor-specific format rather than a standards-compliant UUID.

Which RFC Should You Follow?

For all new software, follow RFC 9562.

It is the current UUID specification and supersedes RFC 4122. Existing UUIDv1, UUIDv3, UUIDv4, and UUIDv5 identifiers remain fully valid under RFC 9562, so older systems continue to interoperate without modification - there's no migration required for identifiers already generated under the older standard.

Most new applications should consider UUIDv7 as the preferred default because it combines chronological ordering with strong randomness while remaining fully compliant with RFC 9562.