UUID generator · Guide
UUID v7 vs ULID: Which Sortable ID Should You Use?
Both UUID v7 and ULID solve the same problem: random identifiers destroy database index locality, because each new row lands in a random spot in the B-tree. Both fix it by putting a timestamp first. The difference is standardisation and encoding.
What they have in common
Both are 128 bits. Both start with a 48-bit Unix millisecond timestamp, followed by random bits. Both are therefore lexicographically sortable by creation time, and both keep inserts clustered at the right edge of an index.
Both are generated client-side with no coordination, which is the property that makes them useful in distributed systems where a database sequence is a bottleneck.
Where they differ
Standardisation: UUID v7 is specified in RFC 9562, published in 2024. ULID is a community specification with no RFC. If your organisation cares about standards compliance or you need interop with tools that speak UUID, v7 wins on paper.
Encoding: UUID v7 uses the familiar 36-character hyphenated hex form. ULID uses 26 characters of Crockford Base32, which is shorter, case-insensitive, and avoids I, L, O and U so it is harder to misread aloud.
Storage: UUID v7 slots into a native UUID column in PostgreSQL or a BINARY(16) in MySQL with zero changes. ULID has no native type anywhere and is usually stored as CHAR(26) or converted to 16 bytes on the way in.
Random bits: v7 has 74 bits of randomness per millisecond; ULID has 80. Both are far past any practical collision concern.
Which to pick
For a new project on PostgreSQL or MySQL, choose UUID v7. Native column types, an RFC behind it, growing first-class support in Postgres 18, Java, .NET and most language ecosystems, and it is a drop-in replacement for v4 in any API that already accepts UUIDs.
Choose ULID when the identifier is user-visible and length matters — URLs, support tickets, anything read over the phone. 26 case-insensitive characters is genuinely nicer than 36 with hyphens.
If you already have ULIDs in production, there is no urgent reason to migrate. They are the same 128 bits with a different alphabet.
The shared caveat: timestamps leak
Both formats expose creation time to anyone holding the ID. That reveals signup order, growth rate and record age — sometimes harmless, sometimes competitive intelligence.
They are also enumerable in a weaker sense than v4: an attacker who sees two IDs knows the time window between them. If IDs are your only access control, that is a problem regardless of version — but if you need opaque identifiers, stay on UUID v4.
Frequently asked questions
Is UUID v7 better than v4?
For database primary keys, yes — index locality is dramatically better. For public identifiers where you do not want to leak creation time, v4 remains the right choice.
Can I store a ULID in a UUID column?
Yes, since both are 128 bits. You convert between the Base32 and hex representations; the underlying bytes are compatible.
Are UUID v7 collisions possible?
With 74 random bits within a single millisecond, generating a collision requires an implausible number of IDs in that millisecond. In practice it does not happen.
Ready to try it?
Open the free browser-based UUID generator and apply what you just read — no sign-up, runs locally.
Open the UUID generator tool