The Problem With Random Identifiers

Any distributed system needs identifiers that don't collide, ideally generated without a central authority. UUIDv4 solved that with 122 bits of randomness, but that randomness comes at a cost most people don't think about until their database gets big.

UUIDv4: Simple, Random, Everywhere

A UUIDv4 looks like f78cd8f3-32c7-45ab-8ca9-75b6c6678be5: 128 bits, of which 122 are random. It's supported natively by almost every database and language, and the collision probability is low enough to ignore in practice.

The downside: because it's fully random, UUIDv4 values inserted as a primary key scatter across a B-tree index instead of appending in order. On large, high-write tables this causes index fragmentation and slower inserts compared to a sequential key.

ULID: Sortable by Design

A ULID (Universally Unique Lexicographically sortable Identifier) encodes a millisecond timestamp in its first 48 bits, followed by 80 bits of randomness, then represents the whole thing in Crockford's Base32. The result: ULIDs generated later always sort after ones generated earlier, as strings, without needing a separate created_at column to order by.

That makes ULIDs a good fit for:

• Primary keys on high-write, indexed tables where insert order matters.
• Event logs and audit trails where newest-first ordering is a core feature.
• Systems that want UUID-like uniqueness without the random-insert index penalty.

When to Just Use UUID

If you're not hitting index fragmentation at scale, or you need maximum interoperability with tools and ORMs that assume standard UUIDs, plain UUIDv4 is still the safe, boring choice, and boring is good for identifiers.

Generate Either in Your Browser

The UUID / ULID Generator produces bulk RFC 4122 v4 UUIDs with optional uppercase and hyphen formatting, useful for seeding test fixtures or generating API keys without opening a terminal.