UUID v4 is random and great for privacy, while v7 is time-ordered and friendlier to databases. Here is how to pick the right one for your use case.
Universally unique identifiers come in several versions. For new systems the practical choice is usually between v4 and v7, and the right answer depends on how you store and sort them.
UUID v4 — random
A v4 UUID is 122 bits of randomness. It carries no timestamp and reveals nothing about when or where it was created, which makes it a solid default when you want identifiers that are hard to guess and leak no metadata.
The trade-off is ordering: because v4 values are random, inserting many of them into a B-tree index scatters writes across the index and can hurt write throughput at scale.
UUID v7 — time-ordered
A v7 UUID embeds a millisecond timestamp in its most significant bits, so values generated later sort after earlier ones. That locality keeps index inserts sequential and plays nicely with database primary keys.
The cost is that a v7 value exposes its creation time, so it is a poor fit when the identifier must not leak timing information.
A quick rule of thumb
- Reach for v7 when the id is a database key and insert performance matters.
- Reach for v4 when the id is public and must not reveal timing.
Whichever you choose, you can generate either version locally in your browser and copy the result straight into your code.