UUID vs ULID: what's the difference?
Both are 128-bit identifiers. The real differences are text encoding, sortability guarantees, and ecosystem support — and UUID v7 changed the debate.
By the Withuse team · Updated
Side by side
| UUID (v4/v7) | ULID | |
|---|---|---|
| Size | 128 bits | 128 bits |
| Text form | 36 chars, hex + hyphens | 26 chars, Crockford base32 |
| Time-sortable | v7: yes / v4: no | Yes (48-bit ms timestamp) |
| Case sensitivity | Lowercase canonical | Case-insensitive |
| Native DB column type | uuid in PostgreSQL, SQL Server, etc. | None — stored as text or bytes |
| Standard | IETF RFC 9562 | Community spec (no RFC) |
What ULID got right
ULID appeared in 2016 to fix v4's biggest operational pain: random keys wreck database index locality. Its layout — a 48-bit millisecond timestamp followed by 80 random bits — makes IDs sort by creation time. The compact, URL-safe base32 encoding is also genuinely nicer to read and paste than hex-with-hyphens.
Why UUID v7 changed the calculus
UUID v7 (standardized in RFC 9562, 2024) adopts essentially the same timestamp-plus-random layout — inside a standard UUID. That means you get ULID's index-friendly ordering while keeping everything the UUID ecosystem already gives you: native uuid column types, driver support, validation in every language, and tooling that has existed for twenty years.
Unless the shorter base32 text form is specifically valuable to you (e.g. user-facing reference codes), v7 now covers ULID's main use case with less friction.
Recommendation
- Greenfield system, standard databases → UUID v7. Native column types and universal library support win.
- Human-facing short codes → ULID's 26-char case-insensitive form is easier to read aloud and type.
- Existing ULID codebase → no urgent reason to migrate; the binary layouts are compatible enough that conversion is possible later.
Need IDs now? Generate time-ordered UUID v7 or any other UUID version instantly in your browser.
Frequently asked questions
Is ULID faster than UUID v7?
Generation speed is not a meaningful difference — both build a 128-bit value from a millisecond timestamp plus random bits, and either way the cost is dominated by the call to your platform's secure random source. Where a real difference can appear is storage and comparison. A ULID is normally kept as its 26-character text form because databases have no native type for it, while a UUID v7 goes into a 16-byte uuid or BINARY(16) column. That makes the UUID roughly half the size in the row and in every index, with integer-style comparisons instead of string ones. If you store a ULID as raw bytes the gap closes, but then you lose the readable encoding that motivated choosing ULID.
Can I convert a ULID to a UUID?
Yes, losslessly in both directions, because both are 128-bit values and only the text encoding differs. Decoding a ULID's Crockford base32 gives you 16 bytes that you can format as a UUID string, and the reverse works the same way. The catch is that a converted ULID is not a valid UUID v7: nothing guarantees its version and variant bits will hold the values RFC 9562 requires, so strict validators will reject it and any code that reads the version digit will see something unexpected. Treat conversion as a storage or transport optimisation, not as a migration path, and if you want genuine v7 semantics generate new v7 values instead.
Should I migrate from ULID to UUID v7?
Only if you are already changing that part of the system. An existing ULID codebase works fine, the identifiers are sound, and rewriting primary keys is disruptive out of proportion to the benefit. The argument for v7 applies mainly to new work: it gives the same time-ordered index behaviour while fitting native database types, standard driver support and every validator that already understands UUIDs, which removes a category of integration friction. A reasonable middle path in a long-lived system is to keep existing ULIDs and adopt v7 for new tables, since the two do not need to interoperate as long as each table is internally consistent.
Why does ULID use base32 instead of hexadecimal?
To make the value shorter and safer to handle. Crockford base32 packs 128 bits into 26 characters against the 36 a hyphenated UUID needs, and its alphabet deliberately omits I, L, O and U — the first three because they are easily confused with 1 and 0, the last to avoid accidental obscenities. The encoding is also case-insensitive and sorts identically as text and as bytes. That combination makes ULID pleasant for identifiers a human will read aloud, retype or scan from a screen, which is exactly the niche where it still beats UUID v7. For machine-to-machine identifiers the readability advantage rarely justifies leaving the UUID ecosystem.