ULID Generator

Timestamp first, randomness second

A ULID is 128 bits: 48 bits of millisecond timestamp followed by 80 bits of randomness, encoded as 26 characters in Crockford base32. Because the timestamp leads, lexicographic sorting of the string equals chronological sorting — which is the entire point.

Why sortability matters in a database

Random identifiers scatter inserts across a B-tree index, splitting pages and fragmenting the index. ULIDs append at the end like an auto-increment key, so insert performance holds at scale while the value stays globally unique and generatable without coordination. This is the same problem UUIDv7 solves, and the two are close cousins.

Crockford base32 is deliberately human-friendly

The alphabet excludes I, L, O and U, removing confusion with 1, 0 and accidental profanity. Decoding is case-insensitive and treats similar characters as equivalent, so a ULID transcribed by a person is far more likely to survive than a hex UUID.

ULID or UUIDv7

Both put a millisecond timestamp first and both sort chronologically. UUIDv7 is a formal IETF standard and fits every existing UUID column and library; ULID is shorter at 26 characters against 36 and has the friendlier alphabet. For new work in an ecosystem with UUID support, v7 is usually the safer choice.

The timestamp is visible

Anyone holding a ULID can read its creation time to the millisecond, and adjacent IDs reveal creation order. That is useful for debugging and a genuine disclosure if record timing is sensitive — an ordering that shows how many accounts were created between two events.