UUID v4 vs UUID v7: Which Identifier Should Developers Use?

Modern applications frequently need identifiers that can be generated independently across servers, devices and services. UUIDs are one of the most common solutions because they allow developers to create identifiers without relying on a central database sequence.

However, not every UUID version behaves in the same way. UUID v4 has been the default choice for many years, while UUID v7 introduces time-based ordering that can be useful for databases, event systems and distributed applications.

This article compares UUID v4 and UUID v7, explains how each format works and provides practical guidance for choosing the right identifier for a modern software project.

What Is a UUID?

A UUID, or Universally Unique Identifier, is a 128-bit value designed to identify a record or object without requiring coordination with a central authority.

A typical UUID is represented as a 36-character string:

550e8400-e29b-41d4-a716-446655440000

UUIDs are widely used for:

• database primary keys;
• API resource identifiers;
• distributed application records;
• event and message identifiers;
• file and document references;
• request and correlation IDs;
• test-data generation.

The UUID version defines how the value is generated and what information is stored inside it.

How UUID v4 Works

UUID v4 values are generated primarily from random or pseudo-random data. A small number of bits are reserved for the UUID version and variant, while the remaining bits provide randomness.

Example:

71d5c86b-1649-4f2f-b05d-7f76f99426db

The digit 4 in the version position indicates that this is a UUID v4.

Advantages of UUID v4

• It is supported by almost every major programming language and framework.
• It does not require access to the current time or hardware information.
• It can be generated independently by multiple services.
• It does not expose the identifier creation timestamp.
• It has an extremely low collision probability when generated correctly.

Limitations of UUID v4

The main limitation is that UUID v4 values are randomly distributed. When they are used as database primary keys, new records are inserted at unrelated positions in a B-tree index.

This may result in:

• more index-page splits;
• reduced cache locality;
• larger index fragmentation;
• less efficient ordered scans;
• unpredictable record ordering.

The impact depends on the database engine, table size, write volume, index design and hardware configuration.

How UUID v7 Works

UUID v7 combines a Unix timestamp with random data. The timestamp is stored in the leading portion of the identifier, which allows UUID v7 values to sort approximately in creation order.

Example:

01965d7e-6ed5-7e86-b3d5-b565ee23af70

The digit 7 in the version position identifies the value as UUID v7.

Advantages of UUID v7

• Values are naturally sortable by creation time.
• Sequential inserts usually provide better database index locality.
• Identifiers can still be generated independently across multiple services.
• It works well for events, logs, records and time-oriented datasets.
• It retains the familiar UUID representation.

Limitations of UUID v7

• Runtime and library support is newer than UUID v4 support.
• The identifier reveals an approximate creation timestamp.
• Clock behavior must be considered in high-throughput systems.
• Older software may not validate UUID v7 values correctly.

UUID v4 vs UUID v7

Developers who want to inspect examples before choosing a format can review this comparison of UUID v4 and UUID v7.

Feature	UUID v4	UUID v7
Generation method	Random data	Timestamp and random data
Chronological sorting	No	Yes
Creation time encoded	No	Yes
Database index locality	Usually weaker	Usually better
Ecosystem support	Excellent	Growing
Distributed generation	Yes	Yes
Approximate time ordering	No	Yes

Database Performance Considerations

Database performance is one of the main reasons developers consider UUID v7.

A B-tree index works most efficiently when new keys are inserted near the end of the existing index. Auto-incrementing integers naturally have this property. Random UUID v4 values do not.

Because UUID v4 values are distributed across the key space, inserts may occur throughout the index. Under a write-heavy workload, this can lead to additional page splits, random disk access and cache pressure.

UUID v7 values begin with a timestamp. New identifiers therefore tend to be greater than older identifiers, causing records to be inserted closer together in the index.

This does not guarantee that UUID v7 will always outperform UUID v4. Actual results depend on:

• the database system;
• the selected column type;
• the storage engine;
• the number of indexes;
• the insert rate;
• batching behavior;
• table size;
• hardware and memory.

Applications with large, frequently updated tables are more likely to benefit from time-ordered identifiers than small applications with modest traffic.

Privacy and Information Exposure

UUID v4 does not directly expose when an identifier was created. Because the value is random, an external observer cannot normally derive a timestamp from it.

UUID v7 includes time information. Anyone who receives the identifier may be able to estimate when it was generated.

This is often acceptable for internal records, event streams, logs and database primary keys. It may be undesirable when creation time is sensitive.

Neither UUID v4 nor UUID v7 should be treated as an authentication secret. A UUID may be difficult to guess, but it is still an identifier. Applications must use proper authorization checks before allowing access to a resource.

When to Use UUID v4

UUID v4 remains a strong choice in many systems.

Use UUID v4 when:

• maximum ecosystem compatibility is required;
• creation time should not be encoded in the identifier;
• the application already uses UUID v4 consistently;
• database insertion order is not an important concern;
• identifiers are primarily exposed through public APIs;
• the data volume is moderate;
• the development framework does not support UUID v7.

UUID v4 is particularly convenient for applications that value simple generation and broad library support.

When to Use UUID v7

UUID v7 is a good option for new applications that need both distributed generation and time-based ordering.

Use UUID v7 when:

• UUIDs are used as database primary keys;
• records should sort approximately by creation time;
• the application creates a large number of records;
• the system processes events or messages;
• index locality is important;
• multiple services must generate identifiers independently;
• the project runtime has reliable UUID v7 support.

Common examples include audit logs, financial transactions, event streams, telemetry records, job queues and distributed business entities.

UUIDs in Distributed Systems

Both UUID v4 and UUID v7 can be generated without contacting a central database. This is useful in microservice architectures because each service can create an identifier before data is persisted.

For example, an order service can generate an order ID, publish an event and send the identifier to another service without waiting for a shared sequence.

UUID v7 adds an ordering benefit. Events created later generally receive larger identifier values, which can make debugging, pagination and data processing more convenient.

However, UUID ordering should not replace an explicit timestamp when exact event ordering is required. Clock drift, concurrency and distributed processing can still produce records that are processed in a different order.

UUIDs as API Resource Identifiers

UUIDs are commonly used in REST APIs:

GET /api/users/71d5c86b-1649-4f2f-b05d-7f76f99426db

Compared with sequential numeric IDs, UUIDs make it harder to infer the number of records in a system. They also allow an application to generate the final resource identifier before saving the record.

UUID v4 is often preferred for public API identifiers because it does not reveal creation time. UUID v7 can still be used, but developers should understand that its timestamp component may expose approximate timing information.

Storage Recommendations

Although UUIDs are normally displayed as strings, storing them as 36-character text values is not always the most efficient option.

Where supported, use a native UUID database type or a 16-byte binary representation. This can reduce storage requirements and improve index efficiency.

For example:

• PostgreSQL provides a native uuid type.
• MySQL can store UUID values using BINARY(16).
• SQL Server provides the uniqueidentifier type.

Developers should also avoid mixing multiple representations of the same UUID inside one application. Decide whether values are lowercase or uppercase and whether they include hyphens, then apply that convention consistently.

Can One Application Use Both Versions?

An application can use both UUID v4 and UUID v7. Different entity types may have different requirements.

For example:

• UUID v7 for internal database primary keys;
• UUID v4 for public sharing tokens;
• UUID v7 for events and audit records;
• UUID v4 for legacy integrations.

However, mixing UUID versions inside the same database column can make behavior less predictable. Consistency is usually preferable within a single table or bounded business domain.

Migration Considerations

A system that already uses UUID v4 does not necessarily need to migrate. Changing primary keys can affect foreign keys, caches, URLs, logs, analytics systems and third-party integrations.

A lower-risk approach is to:

1. retain existing UUID v4 identifiers;
2. use UUID v7 for newly introduced entity types;
3. test database behavior under a realistic workload;
4. verify framework and library support;
5. document the chosen UUID strategy.

Migration should be driven by a measurable problem, not simply by the availability of a newer UUID version.

Final Recommendation

UUID v4 remains the safest general-purpose choice when compatibility, privacy and simple random generation are the main priorities.

UUID v7 is often a better option for new database-oriented applications, event systems and high-volume platforms that benefit from approximate chronological ordering and improved index locality.

The best choice depends on the application architecture:

• Choose UUID v4 for maximum compatibility and non-time-based identifiers.
• Choose UUID v7 for sortable identifiers and database-friendly insertion patterns.

Regardless of the selected version, developers should use a trusted UUID library, store identifiers efficiently and never rely on UUID unpredictability as a substitute for access control.