UUID v4 vs UUID v7

UUID v4 and UUID v7 compared, side by side.

UUID v4 vs UUID v7

What actually differs, and which one to reach for.

Both are 128-bit UUIDs in the same 36-character text format, so anything that accepts one accepts the other. The difference is what fills those bits: v4 is entirely random, while v7 puts a Unix millisecond timestamp in the leading 48 bits and randomness in the rest.

UUID v4 compared with UUID v7
Dimension	UUID v4	UUID v7
Specification	RFC 4122	RFC 9562 (2024)
Layout	122 random bits	48-bit timestamp + 74 random bits
Sortable by creation	No	Yes
Reveals creation time	No	Yes, to the millisecond
Index locality	Random, causes page splits	Sequential, append-friendly
Text format	Same 36-character form	Same 36-character form
Library support	Universal	Widespread since 2024

When to use UUID v4

Public-facing identifiers where creation time is sensitive.
Environments pinned to older libraries without v7 support.
Values that should carry no structure at all.

When to use UUID v7

Primary keys in Postgres, MySQL or any B-tree indexed store.
Event and message IDs that benefit from time ordering.
Replacing an auto-increment key without giving up sortability.

Verdict

Use v7 for new primary keys: it keeps the UUID format your stack already understands while fixing the index fragmentation that random v4 keys cause. Keep v4 where the timestamp would leak information you care about.

Keep Your Services Online

From the maker of MakeUUID

This tool is completely free and ad-free. It's built by the maker of StatusHarbor - uptime monitoring with public status pages for your services. If you're generating IDs for something you're building, StatusHarbor will tell you the moment it goes down.