UUID v4 uses random bits. UUID v7 combines a timestamp with random bits or ordering fields.

Choosing between them depends on whether you need timestamp ordering and whether revealing a timestamp is acceptable.

Here is how their layouts affect that decision.

How UUID v4 is built

A v4 UUID is 122 random bits plus 6 fixed bits for the version and variant markers.

That is all. There is no timestamp, no machine ID, no sequence.

Two v4 UUIDs generated one nanosecond apart look nothing alike:

b076e3c8-fe3c-4475-bad6-bb9dfcc13c0c
e01876de-feae-4a70-a316-028f1ac0c97b

This is a strength when you want IDs that reveal nothing. It is a weakness when you want to sort by creation time or keep a database index compact.

How UUID v7 is built

A v7 UUID starts with a 48 bit Unix timestamp in milliseconds. The remaining 74 bits hold randomness or a combination of randomness and optional counters or finer time information.

The first 12 hex digits encode the timestamp. The later fields depend on the generator:

01a0fa6b-892e-796d-a7a9-e89f53df668c
01a0fa6b-892f-7e16-ad67-604f28e3999b

Two v7 UUIDs with the same millisecond timestamp share their first 12 hex digits. Byte ordering groups values by the encoded timestamp.

Within one millisecond, strict generation order depends on the generator; RFC 9562 permits several approaches to monotonicity.

Clocks on separate machines can also disagree.

Why ordering matters for databases

Most databases store primary keys in a B-tree.

New keys are inserted at the position where they sort. With v4, every insert lands at a random page in the index.

On a table with millions of rows that means the database is constantly touching pages that are not in memory, splitting them, and writing them back.

Insert throughput drops and the index grows with fragmentation.

With v7, keys with later timestamps sort after keys with earlier timestamps.

This can improve insert locality, as the RFC explains. It does not guarantee that every insert appends to the rightmost page.

Measure insert throughput and index size on your own PostgreSQL or MySQL workload before changing a key.

We cover this in depth in Should You Use UUIDs as Primary Keys?.

What v7 gives away

The timestamp in a v7 UUID is readable by anyone who sees it.

A public v7 ID exposes its encoded millisecond timestamp, which depends on the generating clock.

For some, such as anonymous submissions, it could be a privacy concern.

v4 does not encode a timestamp or a node address.

A timestamp and implementation-specific ordering fields can reveal information. An identifier does not replace authorization checks.

Side by side

| UUID v4 | UUID v7

Available random or ordering bits | 122 | 74

Sortable by time | No | Yes

Key distribution | Random | Grouped by encoded timestamp

Reveals encoded time | No | Yes, in milliseconds

Standard | RFC 4122, 2005 | RFC 9562, 2024

Library support | Universal | Most modern libraries

A simple rule

If the UUID will be a database primary key or you will ever sort or range scan by it, use v7.

If the value is a secret, such as a password reset token or an unguessable share link, do not use a UUID at all. Use a dedicated random token from your crypto library.

If you need to hide when something was created, use v4.

If none of the above applies, either works; choose based on ordering and privacy needs.

Generating each one

In JavaScript, crypto.randomUUID() gives you a v4 in every modern browser and in Node.

For v7 the uuid npm package exports a v7() function. PostgreSQL 18 added a native uuidv7() function, and Python 3.14 added uuid.uuid7() to the standard library.

Our guide to generating UUIDs in every language has snippets for each.

You can also make both kinds right now with our online UUID generator. Generate ten v7 UUIDs and watch the prefix tick upward.