Developer

When to Use UUID vs ULID

Published March 17, 2026 · Updated March 17, 2026 · 3 min read

UUIDs are the default for unique identifiers in many systems. ULIDs are a newer alternative that adds sortability. The difference matters most at database scale, where random identifier distribution causes index fragmentation problems that sortable identifiers avoid.

UUID basics

A UUID (Universally Unique Identifier) is a 128-bit identifier formatted as 32 hex digits with hyphens: 550e8400-e29b-41d4-a716-446655440000. UUID v4 (the most common version) is randomly generated — the randomness ensures uniqueness across systems without coordination.

The randomness is also the main drawback for database use. When you insert UUIDs as primary keys in a B-tree index (the default for most databases), random UUIDs scatter insertions across the entire index. This causes page splits and fragmentation, degrading write performance at scale.

ULID basics

A ULID (Universally Unique Lexicographically Sortable Identifier) is also 128 bits but formatted differently: 01ARZ3NDEKTSV4RRFFQ69G5FAV. The first 48 bits encode a millisecond-precision timestamp; the remaining 80 bits are random. This makes ULIDs sortable by creation time — two ULIDs generated in sequence will sort in that order.

For database indexes, this means insertions tend to cluster at the "high end" of the index rather than scattering randomly. This dramatically reduces fragmentation and improves write performance at scale.

When to use UUID

When you need compatibility with systems that expect UUID format
When the IDs don't need to reveal creation time
When you're using UUID v7 (which adds timestamp components — a newer standard that provides similar benefits to ULID)
When working with smaller datasets where index fragmentation isn't a meaningful concern

When to use ULID

When you're inserting high volumes of records and index performance matters
When you want records to be naturally ordered by creation time
When cursor-based pagination is easier with sortable IDs
When you want human-debuggable IDs (ULIDs have the timestamp embedded — you can read when an ID was created)

Privacy consideration: ULIDs embed a timestamp, which means the ID reveals when it was created. If creation time is sensitive information that shouldn't be inferrable from the ID, use UUID v4 instead.

The practical choice in 2026

For new projects: if you're using PostgreSQL, consider UUID v7 (which has native support and sortability), or use ULID with a compatible library. If you're using MySQL with InnoDB, ULID or UUID v7 meaningfully improves write performance at scale compared to UUID v4. For most small applications, the performance difference doesn't matter — pick whatever your framework defaults to.