ULID Generator
ULID
01ARZ3NDEKTSV4RRFFQ69G5FAV
How it works
ULID (Universally Unique Lexicographically Sortable Identifier) is a 128-bit identifier format that combines a 48-bit millisecond-precision timestamp with 80 bits of random data, encoded in Crockford's Base32 (26 characters, no ambiguous characters). Unlike UUID v4, ULIDs are monotonically increasing within the same millisecond — making them dramatically more efficient as database primary keys.
**ULID structure** 01ARZ3NDEKTSV4RRFFQ69G5FAV — 26 characters. First 10 characters: 48-bit timestamp (milliseconds since Unix epoch) — sortable by creation time. Last 16 characters: 80 bits of cryptographically random data. Crockford's Base32 alphabet excludes I, L, O, U (visually ambiguous or profane) for human readability.
**Why ULIDs outperform UUID v4 in databases** B-tree indexes perform best when keys are inserted in order — sequential inserts hit the same leaf node, minimizing page splits and I/O. UUID v4 (fully random) causes ~50% page splits on each insert in a B-tree. ULIDs (time-ordered) insert near the end of the index, behaving similarly to autoincrement integers while remaining globally unique without a central sequence generator. PostgreSQL benchmarks show ULIDs achieving 2–3× higher insert throughput vs. UUID v4 at scale.
**ULID vs UUID v7** UUID v7 (RFC 9562) provides the same timestamp-ordered property in standard UUID format. ULIDs are human-friendly (no hyphens, shorter string representation, readable timestamp prefix). UUID v7 benefits from universal UUID library support. Choose based on whether your ecosystem has better ULID or UUID v7 library support.
Frequently Asked Questions
- A ULID is 26 Crockford Base32 characters. First 10 characters (48 bits): millisecond Unix timestamp — encodes the exact millisecond of generation, making ULIDs lexicographically sortable by creation time. Last 16 characters (80 bits): cryptographically random data — provides uniqueness within the same millisecond. If multiple ULIDs are generated in the same millisecond, the random component is incremented to preserve monotonic ordering within the millisecond (monotonicity mode).
- B-tree indexes perform best with sequential inserts — keys near the end of the index hit the same hot leaf node (better cache utilization, fewer page splits). UUID v4 (fully random 128 bits) inserts are random across the entire index: every insert is likely a page miss. At 10,000 inserts/second into a large table, this means thousands of random I/Os per second — hitting the storage bottleneck. ULIDs (timestamp-prefixed) insert near the 'right end' of the index like autoincrement IDs, maintaining B-tree locality. PostgreSQL benchmarks show 2–3× higher sustained insert throughput for ULIDs vs UUID v4 on large tables.
- Crockford Base32 uses 32 characters: 0-9 and A-Z, excluding I, L, O, U (visually ambiguous with 1, 1, 0, and potentially offensive). This makes ULIDs case-insensitive (I and i both decode as 1), human-transcription-friendly (no confusing characters), and URL-safe (no special characters). Compared to hex (base 16): 26 Base32 chars encode 130 bits; hex would need 32 chars for 128 bits — Base32 is more compact. Standard Base64 uses +, /, = which are URL-unsafe and require encoding in URLs.
- Both achieve timestamp-ordered unique IDs. UUID v7 advantages: standard RFC format (9562), universal UUID library support, 4-byte grouping familiar from existing UUID tooling. ULID advantages: no hyphens (shorter string), human-readable timestamp prefix, Crockford Base32 (URL-safe, no ambiguous characters), specification includes monotonicity within the same millisecond. Choose ULID if your ecosystem has good ULID library support and you value human readability. Choose UUID v7 if you need to drop into existing UUID infrastructure (PostgreSQL UUID type, Java UUID class) without changes.