UUID vs ULID vs Nano ID: Size, Sorting and Collisions

ULID stands for Universally Unique Lexicographically Sortable Identifier. Its specification is a README in the ulid/spec repository on GitHub, not a standards document. A ULID is 128 bits: a 48-bit Unix timestamp in milliseconds followed by 80 bits of randomness. The spec says the timestamp will not run out until the year 10889.

It is written as 26 characters of Crockford's base32, which leaves out I, L, O and U to avoid confusion and is case-insensitive. Because the timestamp comes first, ULIDs sort by creation time as plain text. Within the same millisecond the spec says sort order is not guaranteed unless the generator is monotonic, in which case it increments the random part by one for each new ID.

A ULID is the same size as a UUID and its first 48 bits mean the same thing as a UUID v7's. It does not reserve the version and variant bits that RFC 9562 requires, so a ULID stored in a UUID column is not a valid UUID v7.

Nano ID is a JavaScript library that describes itself as "a tiny, secure, URL-friendly, unique string ID generator". By default it returns 21 characters drawn from a 64-symbol alphabet: A-Z, a-z, 0-9, underscore and hyphen. At 6 bits per character that is 126 random bits, which its README compares with the 122 in a UUID v4.

There is no timestamp and no internal structure, so Nano IDs do not sort by time. Both the length and the alphabet can be changed. The README warns that a shorter ID raises the collision probability and links a calculator for checking a custom size.

UUID v7 and ULID. Both put a 48-bit millisecond timestamp in the most significant bits, so comparing two IDs as text or as bytes compares their creation times first. UUID v4 and Nano ID are random throughout and have no order.

Ordering matters most for database keys. RFC 9562 says that UUIDs which are not time-ordered have poor database index locality, because new values are inserted at random positions in the index. The RFC lists ULID among the earlier time-ordered formats it reviewed when defining v7.

The cost of a leading timestamp is that every ID shows when it was created.

For the two random formats, what matters is the total number of IDs ever generated. For the two time-ordered formats, only IDs created in the same millisecond can collide, so what matters is the generation rate.

As text, a Nano ID is 21 characters, a ULID is 26 and a UUID is 36. In binary, a UUID and a ULID are both 16 bytes. A Nano ID is a string and is stored as one.

UUIDs have built-in database support: PostgreSQL, for example, has a native uuid column type and functions that generate v4 and v7. ULID and Nano ID come from libraries, so the application generates them and the database sees text or bytes.

A ULID can be read aloud or typed without worrying about case. A Nano ID cannot, because a and A are different characters in its alphabet.

Use UUID v7 when you want a time-ordered key that follows a published standard and that databases can generate and store natively. Use UUID v4 when the ID should carry no timestamp and you still want a standard format.

Use ULID when you need time ordering in a shorter, case-insensitive string and a library for your language is acceptable. Use Nano ID for short, URL-safe identifiers that are handled as strings and never need to sort, such as share links or client-side keys.