UUID v4 vs v7: Differences and Which to Use

Both are 128-bit values written as 36 characters, and both are defined in RFC 9562. Six bits are fixed in every UUID: four for the version and two for the variant. The difference is what fills the other 122.

Version 4 fills them with random data. Version 7 puts the number of milliseconds since 1 January 1970 UTC in the first 48 bits and fills the remaining 74 with random bits. The RFC also lets a generator spend some of those 74 bits on a sub-millisecond timestamp or a counter, so that IDs created within the same millisecond still come out in order.

Because the timestamp comes first and is stored big-endian, v7 values sort by creation time whether you compare them as text or as bytes. Order inside a single millisecond is only guaranteed when the generator uses one of the RFC's counter methods.

RFC 9562 gives the reason in its introduction. UUIDs that are not time-ordered, such as v4, have poor database index locality: new values land at random positions in the index instead of next to each other, and the RFC says the effect on B-tree indexes "can be dramatic". Its section on sorting says the real-world difference between index locality and random inserts "can be one order of magnitude or more". Those are the RFC's words, not a benchmark run for this page. Measure on your own schema before relying on a number.

Database support has followed. PostgreSQL 18 has built-in uuidv7() and uuidv4() functions, and its uuid type stores any version. In MySQL 8.4, UUID() returns version 1 values, and UUID_TO_BIN() takes a swap flag that moves the fast-changing time bits to the end to improve indexing. The manual notes that the swap only helps for version 1.

Whatever the version, the RFC recommends storing a UUID as its 128-bit binary value where possible. The 36-character text form takes 288 bits.

With v4 the chance depends on how many IDs exist in total. With v7 only IDs created in the same millisecond can collide, because otherwise the timestamps differ, but there are fewer random bits to separate them: 74 when the generator uses no counter.

Yes: the creation time, to the millisecond. Anyone who sees a v7 ID can read when the record was made. The RFC calls this "a very small attack surface" and says that if a UUID is needed for a security operation, v4 SHOULD be used.

It also says that UUIDs of any version MUST NOT be used as security capabilities, meaning identifiers whose possession alone grants access. For a password-reset link or an API key, use a dedicated random token instead of a UUID.

Only for compatibility. Version 1 stores a 60-bit timestamp counted in 100-nanosecond steps from 15 October 1582, a clock sequence, and a 48-bit node that was traditionally the machine's MAC address. Its text form does not sort by time, because the low bits of the timestamp come first.

The RFC says MAC addresses SHOULD NOT be used within a UUID, and that implementations SHOULD use v7 instead of v1 and v6 if possible.

Use v7 for primary keys and anything else stored in an ordered index, as long as exposing the creation time is acceptable. Use v4 when the ID is shown to people who should not learn when it was created, or when there is no index to protect.

Both are valid UUIDs and fit the same column, so one system can use both. Keep v1 for systems that already depend on it.