A UUID is a 128-bit identifier that can be generated anywhere without asking a central counter. The versions differ in where the bits come from, and that affects performance and sorting.
v4: fully random
Version 4 is 122 random bits. It is simple, widely supported and leaks nothing about when or where it was created. The downside appears when a v4 is used as a primary key in a database with a clustered or B-tree index: new keys land at random positions, which causes more page splits and cache misses than keys that always append at the end.
v7: time-ordered
Version 7 (standardised in RFC 9562) puts a 48-bit Unix timestamp in milliseconds at the front, followed by random bits. New UUIDs sort after older ones, so inserts append to the index like an auto-increment number, while keeping the benefits of UUIDs: no central coordination and hard-to-guess values. For new systems that need UUID primary keys, v7 is usually the better default.
v1 and v6
Version 1 also embeds time, but stores the pieces in an order that does not sort, and traditionally includes a node identifier such as a MAC address, which can leak information. Version 6 is v1 with the fields reordered so it sorts. If you are starting fresh, v7 is simpler.
v3 and v5: names, not randomness
These hash a namespace plus a name (MD5 for v3, SHA-1 for v5), so the same input always gives the same UUID. They are useful for stable identifiers, for example one ID per URL, without a lookup table. Prefer v5 over v3. Neither is a security feature.
Which to choose
- New table with UUID keys: v7.
- Opaque random ID, no ordering needed: v4.
- Same input must always map to the same ID: v5.
- Existing system already on v1: keep it, or migrate to v6 or v7 if sorting matters.
One caution about v7: the timestamp is visible in the ID, so anyone can see when it was created. If creation time is sensitive, use v4.