UUID vs ULID vs NanoID

UUIDs are strictly 128-bit structures. A standard UUID string looks like `f47ac10b-58cc-4372-a567-0e02b2c3d479`. It is composed of 32 hexadecimal characters and 4 hyphens. In storage, UUIDs can be packed into a raw 16-byte binary column (e.g. `uuid` type in PostgreSQL) to minimize overhead. Out of the 128 bits, UUID v4 reserves 6 bits for metadata (variant and version), leaving 122 bits of true entropy.

ULIDs are also 128-bit values, meaning they are binary-compatible with UUID database columns. They are represented using Crockford's Base32 alphabet (`0123456789ABCDEFGHJKMNPQRSTVWXYZ`), which excludes ambiguous letters like I, L, O, and U to prevent human transcription errors. The first 48 bits store a UNIX millisecond timestamp, and the remaining 80 bits provide randomness. A ULID is serialized as a 26-character string, such as `01H7Y8WZ7E8B83M8N7X2H9J4K2`.

NanoID uses a default alphabet of 21 characters containing numbers, lowercase letters, uppercase letters, and hyphens/underscores (`_~0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ`). Unlike UUID and ULID, it does not use a binary standard; it is treated purely as a string. By default, NanoID is 21 characters long, which provides similar security guarantees to UUID v4, but it can be resized to shorter lengths (e.g. 10-12 chars) for compact public tokens.

// Comparing representations and generation in JavaScript/TypeScript
import { v4 as uuidv4 } from 'uuid';
import { ulid } from 'ulid';
import { nanoid } from 'nanoid';

console.log(uuidv4()); // "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d" (36 chars, Hex + hyphens)
console.log(ulid());   // "01H7Y98W6E8X8D8C8K8V8B8M8N" (26 chars, Crockford's Base32)
console.log(nanoid()); // "V1StGXR8_Z5jdHi6B-kY2" (21 chars, URL-safe Base64)

When using a relational database like PostgreSQL or MySQL (InnoDB), primary keys are typically indexed using a B-Tree structure. B-Trees sort entries sequentially to enable rapid range searches and binary lookups. When you insert a row with an auto-incrementing integer or a sortable key, the database appends the new index leaf to the end of the tree, keeping operations fast and data pages tightly packed.

UUID v4 generates completely random values. If you use UUID v4 as a primary key, new rows must be inserted at random locations throughout the B-Tree index. This causes "page splits": the database is forced to split existing index blocks to insert the new random key, leading to massive disk I/O operations, memory overhead, and highly fragmented indexes. As the table grows beyond RAM cache limits, write throughput drops dramatically.

ULID completely mitigates this indexing performance drop. Because the first 48 bits contain a millisecond-precision timestamp, newly generated ULIDs are lexicographically sorted. When rows are inserted, the index is always appended at the end, eliminating random page splits. This allows developers to enjoy the benefits of distributed ID generation without incurring InnoDB performance penalties.

Let's look at the math behind collision risk. UUID v4 has 122 bits of random entropy. The probability of a collision is governed by the Birthday Paradox. To have a 50% chance of a collision, you would need to generate $2.3 \times 10^{18}$ UUID v4s. At a rate of 1 billion IDs generated per second, it would take roughly 73 years to reach this threshold.

ULID has 80 bits of random entropy per millisecond. While 80 bits is less than UUID's 122 bits, the entropy is scope-locked to a single millisecond. To collide, two ULIDs must be generated in the exact same millisecond AND share the exact same 80-bit random value. Furthermore, most ULID libraries generate monotonic random bits: if multiple ULIDs are generated in the same millisecond on the same thread, the random component is incremented by 1, guaranteeing uniqueness.

NanoID's default length of 21 characters with a 64-character alphabet offers $64^{21} \approx 1.4 \times 10^{38}$ possible combinations. This represents roughly 126 bits of entropy. If you reduce NanoID to 12 characters, the combinations decrease to $64^{12} \approx 4.7 \times 10^{21}$, which is still extremely secure for user-facing routes but carries a higher collision risk in massive distributed systems.

Entropy Comparison:
- UUID v4: 122 bits of random entropy
- ULID: 48-bit timestamp + 80 bits of random entropy per millisecond
- NanoID (default 21 chars): ~126 bits of random entropy
- NanoID (custom 12 chars): ~72 bits of random entropy

Generation speed can vary depending on the runtime. Standard UUID generation libraries in Node.js are fast because they rely on native cryptographic bindings (`crypto.randomUUID()`). However, parsing and converting UUIDs between string and binary representation adds overhead in JS apps.

ULIDs require calling the system clock to fetch the millisecond timestamp, followed by random number generation. While slightly more complex than purely random generation, ULID libraries are still capable of generating millions of IDs per second. NanoID is highly optimized for performance; it uses a custom batching algorithm to retrieve random bytes from the OS cryptographical library in chunks rather than single bytes, making it faster than many traditional JavaScript UUID libraries.