UUID v4 vs UUID v7: Which Should You Use?

What they have in common

UUID v4 and UUID v7 are both 128-bit values formatted as the familiar xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx hex string, and both are designed to be globally unique without coordination between systems — no central authority hands them out. A "GUID" is simply Microsoft's name for the same concept; there's no technical difference.

UUID v4: fully random

Per RFC 9562, a v4 UUID is 122 bits of randomness (the remaining 6 bits are fixed to mark the version and variant). Every value is independent of every other — there's no ordering, no timestamp, nothing to infer from one UUID about the next or previous one generated.

That unpredictability is necessary for a value to double as a security token, but it isn't sufficient on its own — a UUID is still an identifier by convention, commonly logged, put in URLs, and treated as non-secret across tooling and infrastructure. If you specifically need a session token, API key, or password-reset token, use your framework's dedicated token generator (or crypto.getRandomValues() sized for your use case) rather than repurposing a UUID library, so it's handled with the operational care actual secrets need — not just because the number of random bits happens to be similar.

UUID v7: time-ordered

A v7 UUID embeds a 48-bit millisecond Unix timestamp in its first bits, followed by random bits for the rest. The practical effect: UUIDs generated later almost always sort after UUIDs generated earlier, because the timestamp dominates the sort order. Two v7 values generated in the same millisecond are still overwhelmingly unlikely to collide, thanks to their random remainder — but unlike v4, that remainder is the only source of unpredictability, so v7 should not be used anywhere a value needs to double as a secret.

Why the difference matters for databases

This is where the choice has real consequences. Most relational databases store primary keys in an index ordered by value. Random v4 UUIDs, inserted as primary keys, scatter writes across the entire index — causing page splits and index fragmentation that get worse as the table grows, which measurably slows down inserts on large tables. Because v7 UUIDs are roughly sequential, new rows land at the end of the index, much like an auto-incrementing integer — so v7 avoids that fragmentation while keeping the collision-resistance and decentralized generation that made UUIDs useful in the first place.

When to use which

• Use v4 for anything where unpredictability matters: tokens, secrets, one-time codes, or identifiers you don't want to leak creation order for.
• Use v7 for database primary keys, event IDs, or any high-volume identifier where insert performance and natural chronological sortability are useful.
• Either works for general-purpose unique IDs with low write volume, where index fragmentation isn't a practical concern.

Generating both

Our UUID / GUID Generator produces cryptographically secure v4 UUIDs using the browser's native crypto.randomUUID(), and v7 UUIDs with an embedded millisecond timestamp — in bulk, with one click to copy.