Generators5 min read
UUIDs let independent systems generate identifiers that will never collide, without asking a central database for the next number. But not all UUIDs are the same: the random v4 you have probably used and the newer, sortable v7 behave very differently in a database. This guide explains the versions, the collision math, and when a UUID beats a plain auto-increment ID. Generate any of them with the UUID Generator.
What a UUID is
A UUID is a 128-bit identifier written as 32 hexadecimal digits in five hyphen-separated groups. Its whole purpose is uniqueness without coordination: any machine can generate one at any time and be confident it will not clash with a UUID generated anywhere else.
550e8400-e29b-41d4-a716-446655440000 8 - 4 - 4 - 4 - 12 (hex digits)
Version 4: random
Version 4 UUIDs are almost entirely random — 122 random bits. They are the common default and are effectively guaranteed unique. Their one weakness is that randomness means consecutive IDs are unordered, which can hurt performance when used as a database primary key, because new rows scatter across the index instead of appending.
Version 7: time-ordered
Version 7 UUIDs place a millisecond timestamp in their leading bits, followed by random bits. This makes them sort in the order they were created while remaining unique, which is far friendlier to database indexes: new rows append in order like an auto-increment key, but without a central counter. For new systems, v7 is often the better default.
ULID
A ULID is a related 128-bit identifier: a millisecond timestamp followed by random bits, encoded in a compact, URL-safe, case-insensitive alphabet (Crockford Base32). Like v7 it is both unique and naturally sortable by creation time, and its encoding is shorter and more readable than the hyphenated hex of a UUID.
Are collisions possible?
In theory, yes; in practice, no. A version-4 UUID has 122 random bits, so you would need to generate billions of UUIDs per second for many years before a collision became likely. For real systems the risk is small enough to ignore entirely, which is why UUIDs are trusted as primary keys across distributed databases.
UUID vs auto-increment ID
A sequential integer ID is compact and naturally ordered, but it requires a central authority to hand out the next value and it leaks information — a competitor can read your user count from an ID in a URL. A UUID can be generated anywhere with no coordination and reveals nothing about volume or order. Choose a UUID for distributed systems and public identifiers; prefer v7 or ULID when you also want index-friendly ordering.
Frequently asked questions
What is the difference between UUID v4 and v7?+
v4 is fully random and unordered. v7 embeds a timestamp so the identifiers sort by creation time, which is friendlier to database indexes while remaining unique.
Are UUIDs guaranteed to be unique?+
Not mathematically, but a v4 UUID has 122 random bits, so a collision is astronomically unlikely and safe to ignore in real systems.
Should I use a UUID as a database primary key?+
Yes, especially in distributed systems. If index ordering matters, prefer v7 or ULID over random v4.
What is a ULID?+
A 128-bit identifier with a leading timestamp and random tail, encoded in a compact sortable alphabet, so it is both unique and ordered by creation time.