UUID v4 vs ULID: what is the difference
Use UUID v4 for pure random IDs and ULID when IDs need to sort by time. ULID puts a 48-bit millisecond timestamp in the high bits, so lexicographic order equals chronological order and database indexes stay friendly; UUID v4 is fully random, which causes random IO on B+tree inserts. Both are 128 bit, and ULID is shorter as text (26 vs 36 characters).
Key differences
| Aspect | UUID v4 | ULID |
|---|---|---|
| Length as text | 36 chars (4 hyphens) | 26 chars, no hyphens |
| Bit layout | 122 random bits + version | 48-bit timestamp + 80 random bits |
| Sorts by time | No — completely unordered | Yes — lexicographic order is time order |
| Database index friendliness | Poor — random writes cause page splits | Good — near-sequential writes |
| Leaks creation time | No | Yes — exposes the creation millisecond |
| Case | Usually lowercase | Crockford Base32, uppercase, no ambiguous chars |
| Standardisation | RFC 9562 international standard | Community spec, not an IETF standard |
UUID v4
Defined by RFC 9562, with 122 bits of pure randomness. Collisions are negligible in practice — you would need roughly 2.7x10^18 values for a one-in-a-million chance. Every language, database and framework supports it natively, so compatibility is the best of anything here. The downside is that it is completely unordered: as a primary key, random inserts make B+trees split pages constantly and write amplification is real.
ULID
ULID puts a 48-bit millisecond timestamp in the high bits, so sorting the strings lexicographically sorts them by creation time. Indexes can write nearly sequentially and insert throughput improves markedly. It uses Crockford Base32 — 26 characters, minus the easily confused I/L/O/U. The trade-offs: it exposes creation time, and it is not a formal standard, so you pull in a library.
How to choose
- Broad compatibility, integrating with third parties → UUID v4
- Database primary key where insert performance matters → ULID
- Creation time must stay hidden → UUID v4
Related tools
FAQ
Can UUID v4 collide
Practically speaking, no. You would need around 2.7x10^18 UUIDs for a one-in-a-million collision chance, so ordinary systems can treat it as unique.
Can I use a UUID directly as a primary key
Yes, but remember it is random — high-frequency inserts split index pages and hurt write performance. At scale, prefer ULID or UUID v7.
Is it risky that ULID exposes creation time
Slightly: competitors or attackers can infer when records were created and roughly how much volume you do. If that bothers you, use UUID v4.