UUID v1 vs v6 vs v7

Three versions at a glance

Here are three IDs made at the same moment, 23 October 2026 at 09:30:00 UTC:

v1  5169dc00-cec4-11f1-9f2a-3f2a9c41d708
v6  1f1cec45-169d-6c00-9f2a-3f2a9c41d708
v7  01a16818-85c0-7b3e-9f2a-4c6d81e05a73

How v1 stores the time

Version 1 counts time in 100-nanosecond steps since 15 October 1582, the day the Gregorian calendar started. That count is a 60-bit number. For our example it is 1f1cec45169dc00 in hex.

The catch is how v1 lays that number out. It splits it into three parts and writes the lowest part first:

• 5169dc00 is the low 32 bits, which change fastest.
• cec4 is the middle 16 bits.
• 1f1 is the top 12 bits, after the version digit 1.

Because the fastest-changing bits come first, the first group wraps around about every 7 minutes. An ID made 5 minutes after our example starts with 043a3a00, so it sorts before the earlier one. In a database index, v1 IDs behave almost like random ones.

After the time come two more fields. The clock sequence (9f2a here, including the variant bits) helps avoid duplicates if the clock goes backwards. The node (3f2a9c41d708) is 48 bits that were meant to be the machine’s network card (MAC) address. Many libraries now use a random node instead, but some, including Python’s uuid1(), still use the real MAC address by default.

How v6 reorders it

Version 6 keeps every field from v1 but writes the timestamp in the natural order, biggest part first:

1. 1
   Start with the same 60-bit timestamp1f1cec45169dc00
2. 2
   Write the top 48 bits first1f1cec45-169d
3. 3
   Add the version digit 6, then the last 12 bits1f1cec45-169d-6c00
4. 4
   Copy the clock sequence and node unchanged1f1cec45-169d-6c00-9f2a-3f2a9c41d708

Now the string, and the 16 bytes behind it, sort by creation time. The conversion loses nothing, so you can turn a v1 into a v6 and back. The npm uuid package has v1ToV6() and v6ToV1() for this.

RFC 9562 says new v6 IDs should use a random clock sequence and node, though it still allows the old MAC address behaviour.

Where v7 is different

Version 7 is not a reshuffle of v1. It is a new design:

• A familiar clock. The first 48 bits are Unix time in milliseconds, the same number Date.now() returns. No 1582 maths.
• No node field. Everything after the time is random, so there is no hardware address to leak.
• Wide support. PostgreSQL 18 (uuidv7()), Python 3.14 (uuid.uuid7()), .NET 9 (Guid.CreateVersion7()) and the npm uuid package all make v7 out of the box. Native v6 support is much rarer.

The trade-off is precision. v1 and v6 count in 100-nanosecond steps, while v7 counts in milliseconds. RFC 9562 lets v7 libraries use some random bits for extra precision or a counter, so IDs from the same millisecond can still sort in order.

Which one to pick

• New tables, new services, new APIs: v7.
• You already store v1 and want ordered indexes: convert to v6, or migrate new rows to v7.
• Another system requires v1: v1, with a random node if your library allows it.

If you are on MySQL, its UUID() function returns v1. UUID_TO_BIN(id, 1) swaps the first and third groups when it stores the bytes, which gives a similar sorting benefit to v6.

Good to know