UUID vs ULID vs Snowflake IDs: Choosing the Right Identifier

Why Unique IDs Matter

Every database record, API resource, and distributed message needs a unique identifier. Auto-incrementing integers work in a single database, but they fail in distributed systems — two servers might generate the same ID simultaneously. They also leak information: user/42 reveals you have fewer than 43 users, and order/1001 lets competitors estimate your order volume.

Unique ID formats solve these problems by generating identifiers that are globally unique without coordination between servers, don't expose business information, and can be generated at the edge without a central authority.

UUID (Universally Unique Identifier)

UUIDs are 128-bit identifiers formatted as 32 hexadecimal characters with four dashes:

UUID v4 is the most common version — 122 bits of random data. The collision probability is astronomically low: you'd need to generate 2.71 quintillion UUIDs to have a 50% chance of a collision. For all practical purposes, every UUID v4 is unique.

UUID v7 (2022 RFC 9562) is the newest version and is quickly becoming the recommended default. It encodes the current timestamp in the first 48 bits, followed by random data. This makes UUIDs sortable by creation time while maintaining uniqueness — solving UUID v4's biggest weakness.

UUIDs are supported natively in every programming language and database. PostgreSQL has a dedicated uuid type. Most languages have built-in or standard library UUID generation.

ULID (Universally Unique Lexicographic ID)

ULIDs are 128-bit identifiers like UUIDs but encoded in Crockford's Base32 for a shorter, more readable format:

The first 48 bits encode a millisecond-precision Unix timestamp; the remaining 80 bits are random. This gives ULIDs two key advantages over UUID v4:

Lexicographic sorting: ULIDs sort chronologically as strings — no special database handling needed. An alphabetical sort of ULID strings is a chronological sort.

Compact format: 26 characters vs UUID's 36 characters (with dashes). The Base32 encoding is case-insensitive and avoids ambiguous characters (0/O, 1/I/L).

The tradeoff: ULIDs don't have an RFC standard, and library support is thinner than UUIDs. However, the format is simple enough that implementations exist for every major language.

Snowflake IDs

Snowflake IDs are 64-bit integers, originally created by Twitter (now X) for generating unique IDs across distributed systems at massive scale:

The format encodes three pieces of information: a 41-bit timestamp (milliseconds since a custom epoch), a 10-bit machine/worker ID, and a 12-bit sequence number (for multiple IDs in the same millisecond on the same machine).

Advantages: Snowflake IDs are 64-bit integers, which means they're compact (8 bytes vs UUID's 16), sort chronologically by default, and are extremely fast to generate (no randomness needed — just a counter).

Tradeoffs: They require a machine ID assignment system to avoid collisions between workers. The 41-bit timestamp overflows after ~69 years from the epoch. And they're numeric only — no alphanumeric encoding.

Discord, Instagram, and many large-scale systems use Snowflake-inspired ID formats. Each customizes the bit allocation for their specific needs.

Head-to-Head Comparison

Size: UUID = 16 bytes / 36 chars. ULID = 16 bytes / 26 chars. Snowflake = 8 bytes / up to 19 digits.

Sortable: UUID v4 = No. UUID v7 = Yes. ULID = Yes. Snowflake = Yes.

Standard: UUID = RFC 9562. ULID = Community spec. Snowflake = No formal standard (vendor-specific).

Randomness: UUID v4 = 122 bits. UUID v7 = 62 bits. ULID = 80 bits. Snowflake = 0 bits (deterministic given timestamp + worker + sequence).

Database support: UUID = Native in PostgreSQL, MySQL 8+, SQLite. ULID = Stored as string or binary. Snowflake = Stored as BIGINT.

Collision risk: All three have negligible collision risk when implemented correctly. UUID v4 has the most randomness; Snowflake has zero collision risk within a single worker (it's deterministic).

Database Performance Implications

The choice of ID format affects database write and read performance, especially at scale:

Clustered indexes: Most databases cluster rows by primary key. Random UUIDs (v4) scatter inserts across the entire B-tree, causing page splits and fragmentation. Time-sorted IDs (UUID v7, ULID, Snowflake) insert sequentially at the end of the index, which is dramatically faster.

Index size: UUID and ULID are 16 bytes; Snowflake IDs are 8 bytes. In tables with millions of rows and multiple indexes, this difference compounds. An index on a Snowflake ID column uses half the memory of a UUID index.

Join performance: Smaller keys mean faster joins. 8-byte integer comparisons are faster than 16-byte binary or 36-character string comparisons.

For most applications, UUID v7 or ULID offer the best balance: globally unique, time-sortable, widely supported, and good enough performance. Choose Snowflake only when you need the absolute smallest key size at massive scale.

How to Choose

Use UUID v7 if you want an industry standard with broad library and database support, time-based sorting, and you're comfortable with the 36-character format.

Use ULID if you want a shorter string representation, case-insensitive formatting, and lexicographic sortability. Ideal for URLs, API keys, and human-readable contexts.

Use Snowflake if you're building a high-throughput distributed system where ID generation speed and 8-byte storage matter. You'll need infrastructure to assign machine IDs.

Use UUID v4 if you need maximum randomness with zero time component (privacy/security sensitive contexts where creation time should not be inferrable from the ID).

Avoid auto-increment integers in any system that might become distributed, any public-facing API (they leak business metrics), or any context where IDs cross system boundaries.

Implementation Tips

Generate IDs on the server, not the client. Client-generated IDs can be tampered with. Server-side generation ensures integrity.

Store as binary when possible. UUIDs stored as `BINARY(16)` take half the space of `CHAR(36)`. Most ORMs and database drivers handle the conversion transparently.

Don't parse IDs for information. Even though UUID v7, ULID, and Snowflake embed timestamps, treat the ID as opaque in your application logic. Use dedicated `created_at` columns for timestamp queries.

Test collision handling. Even with astronomically low collision probability, your code should handle duplicate key errors gracefully — retry with a new ID rather than crashing.

Try the UUID Generator tool to create UUID v4 and v7 values instantly, inspect their components, and copy them for testing.