# UUID v4 vs v7: Which Should You Use?

> Compare UUID versions with a focus on v4 and v7. Understand randomness vs time-sorting, database indexing implications, and when to choose each version.

- URL: https://www.browserutils.dev/blog/uuid-guide-v4-vs-v7
- Published: 2026-04-21
- Updated: 2026-03-16

---

UUIDs (Universally Unique Identifiers) are the default choice for generating unique IDs in distributed systems. They require no coordination between services — every node can generate IDs independently without collisions. But not all UUID versions are equal, and the version you choose has real implications for database performance, sortability, and debugging.

This guide compares the UUID versions that matter in 2026, with a focus on the v4 vs v7 decision that most developers face.

## UUID Structure

All UUIDs follow the same format: 128 bits displayed as 32 hexadecimal characters in five groups:

```
550e8400-e29b-41d4-a716-446655440000
```

The format is `8-4-4-4-12` characters. The version number is encoded in the third group (the `4` in `41d4` above indicates version 4), and the variant is encoded in the fourth group.

Despite sharing the same format, different versions fill those 128 bits very differently.

## UUID v4: Pure Randomness

UUID v4 is the most widely used version. It fills 122 of the 128 bits with random data (6 bits are used for version and variant markers):

```
f47ac10b-58cc-4372-a567-0e02b2c3d479
        version ─┘
```

### Strengths

- **Simple:** Generate a random number, set the version bits, done
- **No coordination:** Two servers will never generate the same UUID (probability of collision with 122 random bits is astronomically low)
- **Privacy:** No embedded information — no timestamps, no MAC addresses
- **Universal support:** Every language, framework, and database supports v4

### Weaknesses

- **Not sortable:** UUIDs generated a second apart look nothing alike. You cannot sort by UUID to get chronological order.
- **Poor index performance:** Random values cause B-tree index fragmentation in databases. New entries are inserted at random positions in the index, leading to page splits and cache misses.
- **Not monotonic:** In high-throughput systems, the randomness means IDs generated in sequence cannot be compared to determine ordering.

### The Database Problem

The index fragmentation issue is significant. In PostgreSQL or MySQL with a UUID v4 primary key, inserting rows is noticeably slower than with sequential integers because the B-tree index is constantly being reorganized. For read-heavy workloads with few inserts, this does not matter much. For write-heavy tables with millions of rows, it can be a real bottleneck.

## UUID v7: Time-Sorted Randomness

UUID v7 was introduced in RFC 9562 (2024) as a modern alternative that addresses v4's biggest weaknesses. It embeds a Unix timestamp in the most significant bits:

```
018f3c5a-7b00-7abc-8def-1234567890ab
│              │
└─ timestamp ──┘
```

The first 48 bits contain a millisecond-precision Unix timestamp. The remaining bits contain random data (with version and variant markers). This means:

- UUIDs generated later have higher values than UUIDs generated earlier
- UUIDs generated in the same millisecond are still unique (random suffix)
- Sorting by UUID gives you roughly chronological order

### Strengths

- **Time-sortable:** Natural chronological ordering without a separate `created_at` column
- **Database-friendly:** Sequential-ish values cause far less B-tree fragmentation than random v4 UUIDs. Insert performance approaches that of auto-increment integers.
- **Embedded timestamp:** You can extract the creation time from the UUID itself
- **Still unique:** The random component ensures uniqueness even at high throughput within a single millisecond

### Weaknesses

- **Timestamp leaks information:** The creation time is encoded in the ID. If your IDs are public, users can determine when a resource was created.
- **Newer spec:** Some older libraries and systems may not have v7 support yet, though adoption has been rapid.
- **Millisecond resolution:** Two UUIDs created in the same millisecond are unique but their relative order within that millisecond is random.

## Performance Comparison

Here is a rough comparison of insert performance with 10 million rows in PostgreSQL:

| ID Type | Insert Rate | Index Size |
|---------|------------|------------|
| BIGSERIAL | ~45,000/sec | Baseline |
| UUID v7 | ~38,000/sec | ~1.4x baseline |
| UUID v4 | ~22,000/sec | ~2.1x baseline |

UUID v7 closes much of the gap with sequential integers. The remaining difference comes from UUIDs being 128 bits versus 64 bits for BIGINT, which affects storage and cache efficiency.

## Other UUID Versions

For completeness, here are the other versions:

**UUID v1** — Timestamp + MAC address. Sortable but leaks the machine's MAC address. Largely obsolete due to privacy concerns.

**UUID v3** — MD5 hash of a namespace + name. Deterministic — the same input always produces the same UUID. Useful for generating consistent IDs from known data.

**UUID v5** — SHA-1 hash of a namespace + name. Same concept as v3 but with a stronger hash. Preferred over v3.

**UUID v6** — Reordered v1 with the timestamp bits arranged for sortability. A precursor to v7, less commonly used.

## Decision Guide

### Use UUID v4 when:

- **Privacy matters:** You do not want creation time embedded in public IDs
- **Maximum compatibility:** Every system on earth supports v4
- **Low write volume:** Index fragmentation is not a concern
- **Simple requirements:** You just need a unique identifier

### Use UUID v7 when:

- **Database performance matters:** Write-heavy tables with millions of rows
- **You need sorting:** Chronological ordering by ID is useful
- **Distributed systems:** Multiple services generating IDs that should be roughly orderable
- **You would otherwise add created_at:** The embedded timestamp can serve double duty

### Consider alternatives when:

- **Short IDs are needed:** UUIDs are 36 characters. Consider NanoID, ULID, or CUID for shorter alternatives.
- **Sequential is fine:** If you have a single database, BIGSERIAL is simpler and faster.
- **Human-readable IDs:** UUIDs are not meant for humans. Use slugs or short codes for user-facing identifiers.

## Generating UUIDs in Code

### JavaScript

```javascript
// v4 — built into the language
crypto.randomUUID(); // "3b241101-e2bb-4d7b-8c6a-4e25c4e10a7d"

// v7 — requires a library (uuid package)
import { v7 } from 'uuid';
v7(); // "018f3c5a-7b00-7abc-8def-1234567890ab"
```

### Python

```python
import uuid

# v4
uuid.uuid4()  # UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479')

# v7 (Python 3.13+)
uuid.uuid7()  # UUID('018f3c5a-7b00-7abc-8def-1234567890ab')
```

### Go

```go
import "github.com/google/uuid"

// v4
id := uuid.New() // random UUID v4

// v7
id, _ := uuid.NewV7() // time-sorted UUID v7
```

### PostgreSQL

```sql
-- v4 (built-in since PostgreSQL 13)
SELECT gen_random_uuid();

-- v7 (requires extension or application-level generation)
-- Most ORMs now support generating v7 before insert
```

## Working with UUIDs

When testing, debugging, or prototyping, you often need to generate UUIDs quickly without writing code. Our [UUID Generator](/tools/uuid-generator) creates both v4 and v7 UUIDs instantly, with options for batch generation and different format options. It also decodes existing UUIDs to show you the version, variant, and — for v7 — the embedded timestamp.

## Migration: v4 to v7

If you are considering migrating an existing system from v4 to v7:

1. **New tables** can use v7 immediately
2. **Existing tables** can continue with v4 — mixing versions in the same column is fine (they are all valid UUIDs)
3. **If re-indexing** a large table, generating new v7 IDs and remapping foreign keys is rarely worth the effort. The benefit of v7 is primarily for future inserts.
4. **Test your libraries** — ensure your ORM, serialization, and validation code handles v7 correctly (they should, since the format is identical)

## Conclusion

UUID v7 is the better default choice for new projects in 2026. It gives you the distributed uniqueness of v4 with significantly better database performance and the bonus of time-sortability. Use v4 when you specifically need the privacy of fully random IDs or when working with systems that only support v4.

The difference will not matter for a table with a thousand rows. It will matter a lot for a table with a hundred million.