Both are standardized 128-bit identifiers, but they work differently. UUID v4 is random, while UUID v7 is designed to be time-ordered.

That difference matters when you're choosing IDs for APIs, distributed systems, and especially database primary keys.

In this guide, we'll compare UUID v4 and UUID v7, explore their advantages and limitations, and look at practical code examples.

1. What Is UUID v4?

UUID version 4 generates an identifier using random or pseudorandom bits.

A typical UUID v4 looks like this:

550e8400-e29b-41d4-a716-446655440000

UUID v4 contains 128 bits, of which 122 are random when generated according to the standard. The remaining six bits identify the UUID version and variant.

Why developers use UUID v4

• Simple to generate in modern programming languages.
• Extremely low probability of accidental collisions when generated correctly.
• Doesn't require coordination with a central ID server.
• Doesn't embed a creation timestamp.
• Suitable for distributed systems and general-purpose identifiers.

UUID v4 limitation

UUID v4 values are not naturally ordered by creation time.

Imagine inserting thousands of records into a database with random UUID primary keys. Depending on the database and index structure, these inserts can touch different areas of the index instead of clustering near recently inserted values.

That can increase index maintenance costs in some workloads.

However, UUID v4 is not automatically a bad database primary key. Actual performance depends on the storage engine, index design, workload, and database configuration.

2. What Is UUID v7?

UUID version 7 was standardized in RFC 9562 in May 2024.

Unlike UUID v4, UUID v7 starts with a 48-bit Unix timestamp in milliseconds.

Example UUID v7 from the RFC:

017f22e2-79b0-7cc3-98c4-dc0c0c07398f

Its layout includes:

• 48 bits: Unix timestamp in milliseconds.
• 4 bits: UUID version (7).
• 2 bits: UUID variant.
• 74 remaining bits: Random data, optionally combined with sub-millisecond precision or counters.

This design makes UUID v7 values approximately sortable by creation time.

Why UUID v7 is useful

UUID v7 combines the benefits of decentralized ID generation with time-based ordering.

This makes it attractive for:

• Database primary keys.
• Event tracking systems.
• Distributed applications.
• Message identifiers.
• High-volume data ingestion.
• Applications that benefit from chronological record ordering.

Unlike a simple auto-incrementing integer, UUID v7 can be generated independently by different services.

However, UUID v7 does reveal approximate creation time, so it may not be suitable when hiding timing information matters.

3. UUID v4 vs UUID v7: Side-by-Side Comparison

Important: UUID v7 doesn't guarantee perfect chronological ordering in every situation. Identifiers generated within the same millisecond, clock adjustments, and implementation details can affect ordering.

4. Why UUID v7 Can Improve Database Performance

Consider an application that inserts 100,000 new records into a table.

With UUID v4, each primary key is randomly distributed across the UUID key space.

With UUID v7, recently generated identifiers generally have similar leading timestamp values.

This can improve insertion locality for some B-tree indexes.

Example scenario

Suppose you're developing an order management system:

Orders
-------------------------
id
customer_id
total
created_at

If your database supports UUID primary keys, either version can identify each order.

But for a write-heavy system where the primary key is indexed, UUID v7 may offer better index locality.

That said, the improvement is not guaranteed for every database. Test the actual database engine and workload before migrating an existing application.

5. Generate UUID v4 in JavaScript

Modern browsers provide crypto.randomUUID().

const id = crypto.randomUUID();

console.log(id);

This generates a random UUID v4 without installing a library.

The method is available in supported secure browser contexts, including HTTPS environments.

In a supported Node.js environment, you can also use:

import { randomUUID } from "node:crypto";

const id = randomUUID();

console.log(id);

Both examples generate version 4 identifiers.

For manual testing, you can also use a free UUID v4 generator to create sample identifiers.

6. Generate UUID v7 in JavaScript

JavaScript's built-in crypto.randomUUID() generates UUID v4, not UUID v7.

For UUID v7, use a compatible UUID library.

One option is the uuid NPM package.

First, install it:

npm install uuid

Then generate a UUID v7 using an ES module:

import { v7 as uuidv7 } from "uuid";

const id = uuidv7();

console.log(id);

The output will be a UUID version 7 identifier.

Use a package release that supports v7, and review its documentation for runtime compatibility.

If you want to inspect a sample before integrating the package into your application, try an online UUID v7 generator.

7. UUID v4 vs UUID v7 for Security

A common misconception is that all UUIDs are secret or impossible to predict.

UUIDs are identifiers, not authentication credentials.

UUID v4 generated using a cryptographically secure random source offers strong unpredictability, assuming the generator is implemented correctly.

UUID v7 includes a timestamp that reveals approximate creation time. Its remaining fields help provide uniqueness and may include random bits or counters.

Neither UUID version should replace access controls, passwords, session security mechanisms, or authorization checks.

For example, exposing an order ID in a URL should never automatically grant access to that order. Your application must still verify the user's permissions.

8. When Should You Choose UUID v4?

Choose UUID v4 when:

• You need a random identifier.
• Time-based ordering isn't important.
• You're working with existing systems that already support v4.
• You want a simple built-in generation method.
• You don't want the UUID itself to reveal an embedded creation timestamp.

For many applications, UUID v4 remains a perfectly reasonable choice.

9. When Should You Choose UUID v7?

Choose UUID v7 when:

• You're designing a new database-backed application.
• Your database workload benefits from time-ordered identifiers.
• Records are created across multiple services.
• You want decentralized IDs with approximate chronological sorting.
• Your programming language or library supports reliable UUID v7 generation.

For new write-heavy database designs, UUID v7 is often worth evaluating.

However, don't migrate an existing application solely because UUID v7 is newer. Test compatibility, index behavior, and migration costs first.

Frequently Asked Questions

Is UUID v7 better than UUID v4?

Not in every situation. UUID v7 is often useful for time-ordered records, while UUID v4 is well suited to general-purpose random identifiers.

Is UUID v7 completely unique?

No UUID version provides a mathematical guarantee of global uniqueness. Correct generation makes accidental collisions extremely unlikely.

Can UUID v7 replace auto-increment IDs?

Yes, in many applications. But storage requirements, index size, join performance, and database workload should be evaluated before choosing a primary-key strategy.

Is UUID v7 always faster than UUID v4?

No. UUID v7 may improve insertion locality in certain databases, but actual performance depends on your implementation and workload.

Does UUID v7 expose the creation date?

It includes a Unix timestamp in milliseconds, which can reveal approximately when the identifier was generated.

Can JavaScript generate UUID v7 without a library?

You can implement the standard yourself, but crypto.randomUUID() only generates UUID v4. A maintained, compatible library is usually the safer choice for UUID v7.

Final Verdict

The choice between UUID v4 and UUID v7 depends on your application's requirements.

Use UUID v4 when you want a straightforward random identifier without time-based ordering.

Consider UUID v7 when you need independently generated identifiers that are approximately sortable by creation time, especially for certain database workloads.

Both versions are useful, and understanding the tradeoffs is more important than automatically choosing the newest one.

For the official technical specifications, read RFC 9562.

What are you using for database primary keys in your projects: UUID v4, UUID v7, or auto-incrementing integers?