ULID vs UUID

ULID and UUID v4 compared, side by side.

ULID vs UUID

What actually differs, and which one to reach for.

Both give you an identifier you can generate anywhere without coordinating with a database. The difference that matters in practice is ordering: a ULID starts with a millisecond timestamp, so ULIDs generated over time sort in the order they were created. A random UUID does not.

ULID compared with UUID v4
Dimension	ULID	UUID v4
Length	26 characters	36 characters with hyphens
Encoding	Crockford's base32 (no I, L, O, U)	Lowercase hexadecimal
Bits of entropy	80 random bits per millisecond	122 random bits
Sortable	Yes, lexicographically by creation time	No
Timestamp embedded	Yes, millisecond precision	No
Standardised	Community spec	RFC 4122 / RFC 9562
Database index locality	Sequential inserts, low fragmentation	Random inserts, page splits

When to use ULID

Primary keys where insert order matters for B-tree index health.
Log or event identifiers you want to sort or range-scan by time.
Anywhere a shorter, case-insensitive, double-click-selectable string helps.

When to use UUID v4

Interop with systems, libraries or column types that expect RFC 4122 UUIDs.
Identifiers that must not leak creation time to whoever sees them.
Maximum entropy per identifier with no timestamp component.

Verdict

For new internal primary keys, ULID (or UUID v7, which brings the same time-ordering into the UUID standard) is usually the better default. Stay on UUID v4 when a spec, a database type or an external API expects it, or when exposing creation time would be a leak.

Keep Your Services Online

From the maker of MakeUUID

This tool is completely free and ad-free. It's built by the maker of StatusHarbor - uptime monitoring with public status pages for your services. If you're generating IDs for something you're building, StatusHarbor will tell you the moment it goes down.