UUID v4 vs UUID v7: Which Should You Actually Use in 2026?

For fifteen years, UUID v4 has been the default choice for unique identifiers across distributed systems. Its randomness guarantees uniqueness without coordination, making it ideal for distributed environments. But with the IETF standardizing UUID v7 in RFC 9562, the landscape is changing. Major databases and ORMs have added support, and developers face a decision that impacts performance, security, and system design.

Structural Differences: Randomness vs Time-Based Ordering

UUID v4 consists of 122 bits of cryptographically secure randomness within the standard 128-bit format. Every bit (except a few format bits) is unpredictable, making two UUIDs generated milliseconds apart completely unrelated. This randomness ensures global uniqueness with negligible collision probability, independent of system state or coordination.

UUID v7, by contrast, embeds a timestamp in its structure. The first 48 bits represent a Unix timestamp in milliseconds, followed with additional time precision and 74 bits of randomness. The result maintains global uniqueness while providing time-based ordering. A v7 UUID generated this morning will sort lexicographically before one generated this afternoon.

Database Performance Implications

When UUIDs serve as primary keys, their structure directly impacts database performance. Most databases use B-tree indexes that maintain entries in sorted order. With v4's random values, inserts occur at random positions within the index, causing fragmentation and page splits. On tables with millions of rows, this significantly degrades insert performance and increases storage requirements.

Time-sortable v7 UUIDs always append to the end of indexes, similar to auto-incrementing integers. This eliminates index fragmentation, reduces page splits, and improves cache locality. Benchmarks show 30-50% improvements in insert throughput when switching from v4 to v7 in PostgreSQL, with comparable space efficiency gains.

The performance advantage compounds as tables grow. For systems handling billions of records, the difference becomes material. High-frequency write systems, particularly those in cloud environments where I/O costs matter, benefit significantly from v7's sequential nature.

When v4 Remains the Superior Choice

Despite v7's database advantages, v4 remains preferable for certain use cases:

1. Security-sensitive identifiers: Session tokens, API keys, and authentication tokens should not reveal creation timestamps. v4's randomness provides better opacity, while v7's embedded timestamp leaks timing information.

2. Distributed tracing: Request IDs in tracing systems benefit from v4's unpredictability. Sequential request IDs could allow inference of system load or request volume.

3. User-facing identifiers: When UUIDs appear in URLs or user interfaces, v4 prevents users from inferring activity patterns from sequential identifiers.

4. Obscuring ordering: In systems where identifier sequencing might reveal business insights, v4's randomness provides better protection.

Migration Considerations

Adopting v7 is straightforward for most systems. The UUID format remains identical, requiring only a one-line code change in most libraries. Database migrations are equally simple since the column type doesn't change.

Key libraries now support v7:

• Node.js: uuid package v10+
• Python: uuid_utils package
• Go: github.com/gofrs/uuid
• PostgreSQL 18: gen_random_uuid_v7() built-in function

Other UUID Versions

While v4 and v7 cover most use cases, understanding other UUID versions provides context:

• v1: Combines timestamp with MAC address. Generally avoided due to privacy concerns (MAC address exposure).
• v3/v5: Deterministic UUIDs generated from namespace and input using MD5 (v3) or SHA-1 (v5). Useful when reproducibility is required.
• v6: Time-sortable variant of v1 with reordered fields. Largely superseded by v7.
• v8: Custom format for application-specific schemes. Allows domain-specific identifier schemes.

Decision Framework

For most modern applications, the choice simplifies to:

• v7 for database primary keys: Especially on tables expected to grow beyond millions of rows.
• v4 for everything else: Session tokens, API keys, request IDs, and user-facing identifiers.

This approach covers approximately 99% of real-world use cases. The decision ultimately depends on your specific requirements around performance, security, and system design. As databases continue scaling and cloud environments optimize for I/O efficiency, v7's advantages for primary keys will likely make it the default for new database schemas.

For developers working across distributed systems, understanding these trade-offs enables more informed design decisions. The UUID landscape has evolved, and with it, our best practices for handling uniqueness at scale.