UUID v4 vs v7: which unique identifier should you choose?

A UUID is a 128-bit unique identifier without central coordination. Version 4, entirely random, has dominated for years. Version 7, more recent (RFC 9562, 2024), embeds a timestamp at the start to produce time-ordered identifiers. This difference, seemingly harmless, radically changes database performance. Here is which to choose.

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit number represented by 32 hexadecimal characters grouped into five blocks, for example 550e8400-e29b-41d4-a716-446655440000. Its purpose: to generate a unique identifier without asking a central authority, which makes it ideal for distributed systems. You can generate some with our UUID generator.

Several versions exist; the most relevant today for record keys are v4 (random) and v7 (time-ordered).

UUID v4 (random)

The UUID v4 is made of 122 random bits (the rest encodes the version and the variant). The probability of collision is so low that it is negligible in practice. It is the default version in most languages and libraries.

• Unpredictable: perfect for tokens or public identifiers that should not be guessable
• No information leak: reveals neither the date nor the order of creation
• Drawback: completely unordered, which strains database indexes

UUID v7 (time-ordered)

The UUID v7 places a Unix timestamp in milliseconds on its first 48 bits, followed by random bits. Two UUID v7 generated at different moments therefore sort in the order of their creation, while remaining unique and practically impossible to guess.

• Sortable: the lexicographic order matches the chronological order
• Index-friendly: insertions happen at the end of the index, like an auto-increment
• Trade-off: it reveals the moment of creation, which can be undesirable for a public identifier

Comparison table

Impact on databases

This is the heart of the matter. Relational databases store their indexes in B-trees (B-tree). Inserting random keys (v4) scatters the writes everywhere in the index, causing fragmentation, page splits and a less efficient cache. On large volumes, insertion performance degrades noticeably.

Ordered keys (v7) always insert at the end of the index, like an auto-incremented identifier. You regain fast insertions, better locality and a more compact index. This is particularly clear with a primary key in InnoDB (MySQL), where the primary key determines the physical order of the rows.

When to choose one or the other

Choose UUID v4 when

• The identifier is exposed publicly and must reveal nothing
• You generate tokens, share links, secrets
• The order and the date of creation must not be guessable
• You want maximum compatibility with the existing setup

Choose UUID v7 when

• The UUID serves as a primary key in a database
• The insertion volume is high and index performance matters
• You want to sort by order of creation without a dedicated column
• Revealing the moment of creation is not a problem

Recommendation

For a database primary key, now prefer UUID v7: you keep the distributed uniqueness of the UUID while avoiding the index penalty of v4. Keep UUID v4 for public identifiers, tokens and secrets, where total unpredictability and the absence of a temporal leak take priority.

Still, check the support for v7 in your language and your ORM: the RFC is recent, but adoption is progressing fast.

Frequently asked questions