UUID vs CUID: Which Should You Use and Why

Unique identifiers are a foundational primitive in software systems. Every database record, every API resource, every distributed event needs a way to be referenced uniquely across systems and time. UUID and CUID are two of the most widely used approaches, and choosing between them has real implications for your database performance, URL readability, and system architecture.

UUID: The Standard

UUID (Universally Unique Identifier) is defined by RFC 4122 and has four versions in common use. UUID v4 is the most prevalent: a randomly generated 128-bit number represented as a 36-character hexadecimal string in the format xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx.

UUID v4 generates identifiers with approximately 5.3 × 10³⁶ possible values, making collision probability effectively zero for practical applications. Two independently generated UUID v4s have roughly a 1 in 5.3 undecillion chance of matching.

UUID v4 characteristics:

• 36 characters (32 hex + 4 hyphens)
• Randomly generated — no correlation between sequential IDs
• Widely supported across every database and programming language
• No information leaked about generation time or sequence

UUID and Database Performance

The random nature of UUID v4 creates a significant problem for database indexes. B-tree indexes — the structure most relational databases use for primary keys — perform best with sequential values. Random UUIDs cause index fragmentation: each new insert lands at a random position in the index rather than appending to the end. At scale, this creates excessive page splits and cache misses.

This is why UUID v7 (timestamp-first, sequential within a millisecond) was introduced. UUID v7 retains global uniqueness while ordering identifiers chronologically, which dramatically improves B-tree index efficiency. For high-volume OLTP workloads, the difference between v4 and v7 can be a 2–5× improvement in insert throughput.

CUID: The Alternative

CUID (Collision-resistant Unique Identifier) was designed with URL-safety, sequential ordering, and horizontal scalability in mind. A typical CUID2 looks like clh3vq4bt0000356sg4c3khlp — 24 lowercase alphanumeric characters with no hyphens.

CUID2 characteristics:

• 24 characters (URL-safe, no hyphens needed)
• Timestamp prefix makes IDs roughly time-sortable
• Includes a fingerprint component to reduce collisions in distributed systems
• Designed specifically for web applications with multiple concurrent generators

The Practical Decision

Use UUID v4 when you need RFC-standard identifiers, maximum ecosystem support, or when the randomness is a security feature (preventing enumeration of resources). Most existing systems, ORMs, and database tools have native UUID support.

Use UUID v7 when you are building a new high-throughput system and database index performance matters. The time-sequential nature eliminates index fragmentation while maintaining global uniqueness.

Use CUID2 when you want shorter, URL-safe identifiers without hyphens and do not need RFC compliance. It is a good choice for new web applications where the identifier will appear in URLs.

Generate UUIDs instantly using the USECALC UUID Generator — supporting both v4 and v7 formats for direct use in development workflows.