T
uuid ulid nanoid database distributed-systems backend

Modern Unique Identifier (ID) Selection Guide: Beyond UUID v4

A comprehensive analysis of UUID v1-v8, ULID, NanoID, CUID2, and Snowflake IDs. Learn how to choose the right unique identifier for your database, distributed systems, and URL safety.

2026-04-11 Use This Tool

Choosing the right unique identifier (ID) is one of the most critical decisions in system architecture. A poorly chosen ID can lead to database performance bottlenecks, security vulnerabilities, or distributed system synchronization issues. For a long time, UUID v4 was the "default" choice for developers. However, as distributed systems and large-scale databases evolved, the limitations of UUID v4 (such as lack of sortability and B-Tree fragmentation) became more apparent.

In this guide, we will dive deep into the evolution of UUIDs, explore modern alternatives like ULID and NanoID, and provide a framework for selecting the best ID for your specific use case.

1. The Evolution of UUID (RFC 4122 to RFC 9562)

The Universally Unique Identifier (UUID) has been the industry standard for decades. Recently, the IETF updated the standard with RFC 9562, introducing new versions specifically designed for modern database and distributed system needs.

UUID v1: Time-based

UUID v1 combines the current timestamp, a clock sequence, and the MAC address of the generator.

  • Pros: Guaranteed uniqueness across space and time (if MAC addresses are unique).
  • Cons: Privacy concerns (exposes MAC address), and non-monotonically increasing if generated on different machines, which can hurt B-Tree performance.

UUID v3 & v5: Name-based (MD5/SHA-1)

These are deterministic. If you provide the same namespace and name, you get the same UUID.

  • UUID v3: Uses MD5.
  • UUID v5: Uses SHA-1 (preferred over v3).
  • Use Case: When you need reproducible IDs based on unique inputs (e.g., generating an ID from a URL).

UUID v4: Random

The most common version, composed of 122 random bits.

  • Pros: Extremely low collision probability, no sensitive information exposed.
  • Cons: Completely non-sortable. When used as a primary key in a B-Tree index (like MySQL's InnoDB), it causes massive "index fragmentation" and "page splits," leading to severe performance degradation as the table grows.

The New Generation: UUID v6, v7, and v8

RFC 9562 introduced these to solve the sortability problem of v4 while keeping the UUID format.

UUID v7: The New Gold Standard

UUID v7 is time-ordered. It uses a 48-bit Unix timestamp (millisecond precision) followed by random bits.

  • Why it's great: It is lexicographically sortable. When used as a database primary key, new records are appended to the end of the B-Tree, minimizing page splits and keeping performance high.
  • Recommendation: For almost all new projects, UUID v7 should replace UUID v4 as the default ID.

UUID v6

Essentially a re-ordered UUID v1 to make it sortable. Use it only if you have a legacy dependency on the UUID v1 structure but need sortability.

UUID v8

Allows for custom implementation while maintaining the UUID structure. Useful for proprietary systems that need to embed specific metadata within the 128-bit ID.

2. Deep Dive into Modern Alternatives

While UUIDs are standard, several alternatives have gained popularity due to specific advantages in readability, length, or distributed generation.

ULID (Universally Unique Lexicographically Sortable Identifier)

ULID is a strong competitor to UUID v7.

  • Structure: 48-bit timestamp + 80 bits of randomness.
  • Encoding: Uses Crockford's Base32, making it only 26 characters long (compared to 36 for a standard UUID string).
  • Pros: URL-safe, case-insensitive, sortable, and visually shorter than UUID.
  • Cons: Not a standard UUID format (some older database types might not handle it as efficiently as a native 128-bit UUID/GUID type).

NanoID: The Small and Fast Alternative

NanoID is often used in front-end and web applications.

  • Pros: Much smaller than UUID, highly customizable alphabet, and faster than UUID v4.
  • Security: Uses cryptographically strong random generators.
  • Use Case: Perfect for URL shorteners, public-facing record IDs where short, non-guessable strings are required.

CUID2: The Next Generation of Secure IDs

CUID2 is designed to be secure and horizontal-scale friendly.

  • Features: Highly collision-resistant, non-sequential (prevents enumeration attacks), and portable across different programming languages.
  • Use Case: When security and horizontal scalability are more important than strict time-sortability.

Snowflake ID: The Distributed Heavyweight

Originally developed by Twitter, Snowflake IDs are 64-bit integers.

  • Structure: Timestamp + Worker ID + Sequence Number.
  • Pros: Extremely fast to generate, fits into a standard BIGINT (64-bit), and time-ordered.
  • Cons: Requires a centralized or coordinated "Worker ID" assignment to prevent collisions in a cluster.

3. Comparison Table

Feature UUID v4 UUID v7 ULID NanoID Snowflake CUID2
Length 128 bits 128 bits 128 bits Variable 64 bits Variable
Sortable No Yes (Time) Yes (Time) No Yes (Time) No
Format Hex (8-4-4-4-12) Hex Base32 Alphanumeric Integer Alphanumeric
Collision Risk Negligible Negligible Extremely Low Configurable Zero (if coordinated) Extremely Low
Readability Poor Poor Good Excellent Good Good
DB Native Type Yes Yes No (Binary/String) No (String) Yes (BIGINT) No (String)

4. Best Practices for Choosing an ID

For Database Primary Keys

  • Use UUID v7 if your database supports 128-bit UUIDs (PostgreSQL, modern MySQL, SQL Server). It provides the best balance of uniqueness and B-Tree performance.
  • Use Snowflake ID if you are building a massive distributed system and want to save space with 64-bit integers.
  • Avoid UUID v4 for large tables; the random insertions will destroy your write performance.

For Public URLs

  • Use NanoID or SQID. They are short, URL-safe, and visually pleasing.
  • Short UUIDs (Base58 or Base62 encoded UUIDs) are also a great option to keep the underlying uniqueness while providing a cleaner URL.

For Distributed Systems (Microservices)

  • ULID or KSUID are excellent because they don't require a central coordinator (unlike Snowflake) but still provide time-based ordering, which is useful for debugging and logging.

5. Code Examples

Generating UUID v7 in Node.js

With the uuid package:

const { v7: uuidv7 } = require('uuid');
console.log(uuidv7()); // e.g., '018c3b7a-6b5d-7e8c-9a1b-2c3d4e5f6g7h'

Generating ULID in Python

Using the python-ulid library:

from ulid import ULID
ulid = ULID()
print(ulid) # e.g., '01H6P7XG6WJ9S5H8K4M6N7B2P1'

6. FAQ Section: Common Pitfalls

Q: Can I convert my existing UUID v4 to UUID v7? A: No, the bits are structured differently. You can, however, start using UUID v7 for new records. Most databases can store both in the same UUID column.

Q: Is NanoID as secure as UUID? A: Yes, if the length and alphabet are chosen correctly. A 21-character NanoID has a similar collision probability to UUID v4.

Q: Why not just use auto-incrementing integers? A: Auto-increments are great for small, single-node databases. However, they expose your data volume to competitors (e.g., user/5000 tells someone you have 5,000 users) and are hard to manage in distributed systems.

7. Conclusion

In 2026, there is rarely a reason to stick with UUID v4 for database primary keys. The rise of UUID v7 has provided a standardized, time-ordered solution that solves performance issues while maintaining compatibility. For specialized needs, ULID offers better readability, and Snowflake IDs offer maximum efficiency in large-scale distributed architectures.

Evaluate your needs for sortability, readability, and performance before committing to an ID scheme. Your future self (and your database) will thank you.

Back to Blog UUID Generator →