Cryptographic Security: Securing Key Buffers and Generating ULID Generator Outputs

A ULID (Universally Unique Lexicographically Sortable Identifier) is a 26-character identifier designed to fix a specific annoyance with UUIDv4: totally random identifiers don't sort in any meaningful order, which means using them as a database primary key causes constant index page splits as new rows land in random locations across a B-tree. A ULID solves this by splitting its 128 bits into two parts — a 48-bit timestamp representing milliseconds since the Unix epoch, encoded first, followed by 80 bits of cryptographically random data. Because the timestamp component comes first, ULIDs generated later in time sort lexicographically after ULIDs generated earlier, giving you UUID-like global uniqueness with the insert-friendly locality of an auto-incrementing key. The whole 128-bit value is encoded using Crockford's Base32 alphabet, which excludes visually ambiguous characters like I, L, O, and U to reduce transcription errors.

[!TIP] Need sortable unique IDs for a new schema? Try our free, local ULID Generator to generate them completely offline.

---

Anatomy of a ULID

01ARZ3NDEKTSV4RRFFQ69G5FAV
└────┬────┘└────────┬────────┘
 Timestamp (10 chars)  Randomness (16 chars)
 48-bit ms since epoch  80 bits of entropy

• Timestamp segment (10 characters): encodes the current millisecond timestamp, making every ULID roughly chronological even across different generating machines, as long as their clocks agree.
• Randomness segment (16 characters): filled using a cryptographically secure random source (crypto.getRandomValues in the browser), giving enough entropy that collisions within the same millisecond are practically negligible for any realistic write volume.

ULID vs UUIDv4: When Sort Order Matters

• UUIDv4 is 122 bits of pure randomness (with 6 fixed bits for version/variant markers), formatted as 36 characters with hyphens. It offers no ordering information at all — two UUIDs generated seconds apart look completely unrelated.
• ULID trades a slice of that randomness for a leading timestamp, which means a range of ULIDs generated over time can be queried with a simple string comparison (WHERE id > '01ARZ3...') to approximate a time range, and clustered indexes stay append-mostly instead of fragmenting.

This makes ULIDs a strong fit for event logs, audit trails, and any primary key where you'll frequently want "give me everything created after X" without a separate timestamp column.

Where ULIDs Fit Alongside Other ID Schemes

ULIDs sit in a broader family of "sortable random ID" schemes that includes Twitter's Snowflake IDs and KSUID, all built around the same core insight: pack a coarse timestamp into the high-order bits so ordering falls out of a simple lexicographic or numeric comparison, then fill the rest with randomness for uniqueness. Snowflake IDs are numeric and typically require a coordinated worker/shard ID to avoid collisions across machines, which adds operational complexity a purely random ULID avoids. KSUID uses a similar timestamp-plus-randomness structure to ULID but with a different epoch and byte layout. Choosing between them usually comes down to ecosystem fit — which libraries and datastores already expect a given format — more than any dramatic technical difference.

A Note on Sortability Guarantees

ULIDs sort correctly across different milliseconds, but within the same millisecond, ordering falls back to the random component, which carries no chronological meaning. If you need strict monotonic ordering even for IDs minted in the same millisecond on the same process, look for a "monotonic" ULID variant that increments the random portion instead of re-randomizing it.

---

Conclusion

ULIDs give you most of what makes UUIDs convenient — decentralized, collision-resistant uniqueness — while fixing the indexing and sortability problems that come from pure randomness. For any schema where insertion order or a rough creation timestamp matters, they're a practical drop-in replacement for a random UUID primary key.