# UUID v4 vs v7: Differences and Which to Use

> UUID v4 is 122 random bits. UUID v7 starts with a millisecond timestamp, so IDs sort by creation time. Bit layouts, collision odds and when to use each.

- URL: https://generate.now/guides/uuid-v4-vs-v7
- Published by: Hyperdusk Ltd (https://hyperdusk.com)
- Published: 2026-11-11
- Last updated: 2026-11-11

## The short answer

UUID v4 is 122 random bits with no order. UUID v7 starts with a 48-bit Unix timestamp in milliseconds, followed by 74 random or counter bits, so newer values sort after older ones. Use v7 for database keys that benefit from ordered inserts, and v4 when an ID must not reveal when it was created.

## Key differences

**UUID v4 and v7 side by side**

|   | UUID v4 | UUID v7 |
| --- | --- | --- |
| Defined in | RFC 9562, section 5.4 | RFC 9562, section 5.7 |
| Layout | 122 random bits | 48-bit Unix timestamp in milliseconds, then 74 random or counter bits |
| Sorts by creation time | No | Yes, as text and as raw bytes |
| Reveals creation time | No | Yes, to the millisecond |
| Random bits | 122 | Up to 74 |
| Which IDs can collide | Any two IDs ever generated | Only IDs created in the same millisecond |
| Text length | 36 characters | 36 characters |
| Timestamp range | None | Until about the year 10889 |

## What is the difference between UUID v4 and v7?

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.

## Why is UUID v7 recommended for database primary keys?

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.

## How likely is a UUID collision?

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.

**Chance of at least one collision**

| Version | IDs generated | Chance of a collision |
| --- | --- | --- |
| v4 | 1 billion in total | 1 in 1.06 × 10^19 |
| v4 | 1 trillion in total | 1 in 1.06 × 10^13 |
| v4 | 10^15 in total | 1 in 10.6 million |
| v4 | 2.71 × 10^18 in total | 1 in 2 |
| v7 | 1,000 in the same millisecond | 1 in 3.78 × 10^16 |
| v7 | 1 million in the same millisecond | 1 in 3.78 × 10^10 |
| v7 | 1 billion in the same millisecond | 1 in 37,800 |
| v7 | 1.62 × 10^11 in the same millisecond | 1 in 2 |

_Computed with the birthday bound, p = 1 − e^(−n(n−1)/2N), where N is 2^122 for v4 and 2^74 for v7 filled with random bits. The v7 rows apply to independent generators: a single generator that increments a counter within the millisecond does not collide with itself._

These figures assume a cryptographically secure random source, which the RFC says implementations SHOULD use. A predictable or badly seeded random source makes collisions far more likely than the table suggests.

## Does UUID v7 leak information?

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.

## When is UUID v1 still the right choice?

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.

## Which should you use?

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.

## Tools for this

- [Generate UUID v4 or v7 values](https://generate.now/uuid): UUID Generator. Generates v4, v7 and v1 UUIDs in bulk and decodes a pasted UUID, including the timestamp inside a v7.
- [Generate a random API key or token](https://generate.now/api-key): API Key Generator. For secrets whose possession grants access, where a UUID is the wrong tool.

## Sources

Primary sources, read on 2026-11-11.

- [RFC 9562: Universally Unique IDentifiers (UUIDs)](https://www.rfc-editor.org/rfc/rfc9562): IETF. Bit layouts of v1, v4 and v7, the index-locality rationale, sorting, storage and security considerations.
- [PostgreSQL 18: UUID Functions](https://www.postgresql.org/docs/current/functions-uuid.html): PostgreSQL Global Development Group. The built-in uuidv4() and uuidv7() functions and the v7 timestamp range.
- [PostgreSQL 18: UUID Type](https://www.postgresql.org/docs/current/datatype-uuid.html): PostgreSQL Global Development Group. The uuid column type, which stores any UUID version.
- [MySQL 8.4 Reference Manual: Miscellaneous Functions](https://dev.mysql.com/doc/refman/8.4/en/miscellaneous-functions.html): Oracle. UUID() returns version 1 values; the UUID_TO_BIN() swap flag and its limits.

## Related guides

- [UUID vs ULID vs Nano ID: Size, Sorting and Collisions](https://generate.now/guides/uuid-vs-ulid-vs-nanoid): UUID, ULID and Nano ID compared: length, alphabet, random bits, whether they sort by time, and computed collision odds. With a guide to choosing one.
- [Password vs Passphrase: Which Is Stronger?](https://generate.now/guides/password-vs-passphrase): A random 12-character password and a six-word passphrase are about equally strong. Entropy tables for both, and what NIST SP 800-63B says about length.
- [MD5 vs SHA-1 vs SHA-256 vs SHA-512: Which Hash to Use](https://generate.now/guides/md5-vs-sha1-vs-sha256): MD5 and SHA-1 have known collisions; SHA-256 and SHA-512 are NIST-approved. Digest sizes, security strengths, and why none of them should store passwords.

[All guides](https://generate.now/guides)