What Is UUID v7? Time-Ordered UUIDs Explained

The Layout of a Version 7 UUID

0192f0c1-6a4b-7c3d-9e2f-0a1b2c3d4e5f
|-------------|  ^
 48-bit unix ms  version 7
                     ^ variant (8, 9, a or b)

The first 12 hex digits are the timestamp. A 48-bit millisecond counter won't overflow until the year 10889, so there's no practical limit.

Why the Timestamp Comes First

Database indexes store keys in sorted order. With random v4 keys, each insert lands somewhere random in the index, splitting pages and spreading writes across the whole structure. With v7, new keys go near the end, like auto-incrementing integers, while still being unique without coordination. UUID v4 vs UUID v7 compares the two in detail.

How Strict Is the Ordering?

Not perfectly strict, and it's worth knowing the limits:

• Same generator, same millisecond. RFC 9562 describes optional methods, such as using rand_a as a counter or extra sub-millisecond precision, to keep values from one generator increasing. Implementations differ in whether and how they do this.
• Different machines. IDs from different servers depend on their clocks. Values created in the same millisecond on two machines can interleave, and clock skew can put a later ID before an earlier one.
• Clocks moving backwards. NTP adjustments can move a clock back; good generators handle this, but ordering isn't guaranteed across such events.

Treat v7 ordering as "roughly by creation time", which is ideal for index locality, not as a reliable event sequence. If exact order matters, store a proper timestamp or sequence number too.

Reading the Timestamp

Because the first 48 bits are a Unix timestamp in milliseconds, you can recover approximately when the ID was generated:

const ms = parseInt('0192f0c16a4b', 16); // first 12 hex digits
new Date(ms).toISOString();

The UUID decoder does this for you, and how to get the timestamp from a UUID covers v1, v6 and v7. Note it's the generator's clock reading, not proof of when a record was stored.

Privacy Considerations

That embedded timestamp is a trade-off. Anyone who sees a v7 ID can tell roughly when it was created, and IDs created close together look similar. For many uses, such as order IDs and internal records, that's fine. If creation times are sensitive, for example in public URLs where timing reveals user activity, prefer v4 for public identifiers, perhaps alongside v7 internal keys. Unlike version 1, v7 contains no hardware address.

Where UUID v7 Is Supported

• PostgreSQL 18: uuidv7()
• .NET 9: Guid.CreateVersion7()
• Python 3.14: uuid.uuid7()
• JavaScript: the uuid npm package's v7()
• Go: github.com/google/uuid's NewV7()

How to generate UUID v7 has examples for each.

Try It

The UUID v7 generator creates version 7 UUIDs in your browser using the Web Crypto API for the random bits. Generate a batch and you'll see the shared, increasing prefix; paste any of them into the decoder to read the timestamp back.

Version 7 vs Other Time-Based Versions

The Unix epoch makes v7 timestamps easy to read with everyday tools, and dropping the node field avoids the privacy problems of v1.

Practical Tips

• Generate v7 IDs as close to the moment of creation as possible, so the timestamp is meaningful.
• Don't parse the timestamp for business logic; store a real timestamp column.
• Keep clocks synchronised (NTP) on servers that generate IDs, which helps ordering.
• If you expose v7 IDs publicly, be comfortable with people inferring creation times.

Summary

UUID v7 puts a millisecond timestamp in front of random bits, giving unique IDs that sort roughly by creation time. Great for database keys; just remember the ordering isn't strict and the timestamp is visible.