UUIDv4 vs UUIDv7: Which Fits Your IDs and Write Patterns?

UUIDv4 and UUIDv7 both generate unique identifiers, but they differ fundamentally in how they are constructed, which affects database write performance and sortability. If you need random, unguessable IDs, choose UUIDv4; if you need time-ordered, index-friendly IDs for high-write workloads, choose UUIDv7.

Background: Why UUID Versions Matter

Universally Unique Identifiers (UUIDs) are 128-bit numbers standardized by RFC 4122. The standard defines several versions, each with a different generation method. UUIDv4 is the most widely used because it relies entirely on random numbers, making it simple and collision-resistant. UUIDv7, a newer proposal (draft-ietf-uuidrev-rfc4122bis), encodes a Unix timestamp in the most significant bits, followed by random bits. This design gives it time-ordered properties, which can significantly improve database index performance.

How UUIDv4 Works

UUIDv4 generates 122 random bits (the remaining 6 bits are fixed for version and variant). The result looks like 550e8400-e29b-41d4-a716-446655440000. Because it is purely random, there is no correlation between the ID and when it was created. This makes UUIDv4 ideal for scenarios where IDs must not reveal creation time or order, such as public API tokens, file names, or any identifier exposed to users where predictability is a security concern.

How UUIDv7 Works

UUIDv7 uses a 48-bit Unix timestamp (milliseconds since epoch) as the first component, followed by 74 random bits. A typical UUIDv7 looks like 018f6b3a-4e7b-7a1c-9d2e-3f4a5b6c7d8e. Because the timestamp is in the most significant bits, UUIDv7 values are roughly sortable by creation time. This property allows databases to use B-tree indexes efficiently, as new IDs are appended near the end of the index rather than inserted randomly, reducing page splits and index fragmentation.

Choosing Based on Write Patterns

Your application’s write pattern is the primary factor in choosing between UUIDv4 and UUIDv7.

• High-volume inserts: If you insert millions of rows per day, UUIDv7 reduces index maintenance overhead. Random UUIDv4 inserts cause frequent index page splits, leading to slower writes and larger index storage.
• Time-series data: UUIDv7 naturally orders records chronologically, which helps range queries (e.g., “get all records from the last hour”). UUIDv4 offers no such ordering.
• Distributed systems: Both versions are suitable for distributed generation because they require no central coordination. However, UUIDv7’s timestamp component can leak creation time, which may be undesirable in some privacy-sensitive contexts.
• Offline creation: Both can be generated offline, but UUIDv7’s timestamp requires a reliable clock. If system clocks are not synchronized, UUIDv7 ordering may be slightly off.

Common Problems and Misconceptions

A common misconception is that UUIDv7 is always better because it is newer. However, UUIDv7’s time-based nature can cause issues:

• Timestamp collision: If two IDs are generated in the same millisecond, the random bits still ensure uniqueness, but the sort order may not reflect actual creation order.
• Clock rollback: If a system clock moves backward, UUIDv7 may generate IDs that are out of order, potentially causing issues in systems that rely on strict monotonicity.
• Security: UUIDv7 reveals the approximate creation time, which can be a problem for IDs that should not expose internal operations (e.g., user IDs in a public profile).

Performance Comparison

In practice, the performance difference between UUIDv4 and UUIDv7 becomes noticeable at scale. With millions of rows, a UUIDv4 primary key can cause:

• Increased index size due to page splits.
• More random I/O on disk-based databases.
• Slower insert throughput in OLTP workloads.

UUIDv7 mitigates these by keeping new entries clustered. However, for small datasets (under a few hundred thousand rows), the difference is negligible. Also, some databases (like PostgreSQL) offer native UUID types, but they treat both versions equally; the benefit comes from the index structure, not the data type.

Alternatives to Consider

Beyond UUIDv4 and UUIDv7, other ID schemes exist:

• ULID: 128-bit, time-sortable, and lexicographically sortable, similar to UUIDv7 but with a different layout.
• Snowflake IDs: 64-bit, time-ordered, often used in distributed systems (e.g., Twitter’s Snowflake). They are smaller but require a unique worker ID.
• Auto-increment integers: Simple and compact, but not suitable for distributed systems or when IDs must be unguessable.
• UUIDv6 and UUIDv8: Other proposed versions that offer different trade-offs between time-ordering and randomness.

Each has its own trade-offs in terms of size, sortability, and security. The choice depends on your specific requirements for distribution, privacy, and performance.

Frequently Asked Questions

Is UUIDv7 a standard?

UUIDv7 is part of the draft revision of RFC 4122 (draft-ietf-uuidrev-rfc4122bis). It is not yet an official IETF standard, but it is widely implemented in libraries and databases. Many consider it a de facto standard for new applications.

Can I use UUIDv7 as a primary key in MySQL?

Yes, MySQL supports storing UUIDs as CHAR(36) or BINARY(16). For better performance, store UUIDv7 as BINARY(16) and use the native UUID_TO_BIN function with the swap flag to maintain sortability. However, MySQL’s InnoDB does not automatically optimize for random vs. sequential keys; the benefit comes from the index structure.

Does UUIDv7 guarantee uniqueness?

UUIDv7 uses 74 random bits, so the probability of collision is extremely low (about 1 in 2^37 for 1 billion IDs). It is not absolute, but it is practically unique for most applications. If you need guaranteed uniqueness, use a centralized sequence or a combination of timestamp + random + node ID.

Should I use UUIDv4 for public API keys?

Yes, UUIDv4 is generally preferred for public identifiers because it is unpredictable and does not leak creation time. UUIDv7’s timestamp could reveal when a resource was created, which might be sensitive information.

Can I convert a UUIDv4 to UUIDv7?

No, you cannot convert between versions because the bit layouts are incompatible. You would need to generate a new ID. If you are migrating, you may need to map old IDs to new ones, which can be complex.

Which version is better for a new project?

For most new projects, especially those with high write volumes, UUIDv7 is a strong choice because it improves database performance. However, if you need unguessable IDs or do not want to reveal creation times, stick with UUIDv4. Evaluate your specific use case before deciding.

Related

• Create an Index in PostgreSQL: A Practical Guide
• Disk Offline Signature Collision: Causes & Fixes
• Tecno Phantom X Curved AMOLED Dual Front Cameras India