UUID Versions Explained: V1 vs V4 vs V7

Meta Description: Understand the differences between UUID v1, v4, v5, and v7. Learn which UUID version to use for databases, APIs, and distributed systems.

UUIDs are everywhere. They're in your database primary keys, API responses, session tokens, and message queues. But did you know there are multiple versions of UUIDs — and picking the wrong one can hurt your application's performance?

This guide explains how each UUID version works, what it's good for, and which one you should actually use.

What Is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit identifier that's designed to be unique across space and time without requiring a central authority. It's formatted as 32 hexadecimal digits in five groups separated by hyphens:

550e8400-e29b-41d4-a716-446655440000

The structure is: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Where:

• M indicates the UUID version (1–8)
• N indicates the variant (usually 8, 9, a, or b for RFC 4122)

The total keyspace is 2^122 unique values (for version 4) — that's about 5.3 × 10^36 possible IDs. For context, you could generate a billion UUIDs per second for 100 years and the probability of a collision would still be astronomically small.

Generate UUIDs instantly with our UUID Generator.

UUID Version 1: Timestamp + MAC Address

How It Works

UUID v1 combines:

• A 60-bit timestamp (100-nanosecond intervals since October 15, 1582)
• A 14-bit clock sequence (to handle clock adjustments)
• A 48-bit node ID (typically the machine's MAC address)

Example: 6fa459ea-ee8a-11e0-9000-0800200c9a66
                         ^
                    version 1

Pros

• Naturally sortable by creation time (with caveats — the timestamp bits aren't in the most significant position in the standard format)
• Guaranteed unique per machine without coordination, since the MAC address is unique
• Includes creation time — you can extract the timestamp from the UUID

Cons

• Privacy concern: The MAC address reveals which machine generated the UUID. In security-sensitive contexts, this is a leak.
• Not random: UUIDs from the same machine are predictable and sequential
• Clock dependency: If the system clock goes backward, duplicates are possible without proper clock sequence handling

When to Use V1

Rarely, in modern systems. It was the original design and sees legacy use, but v4 and v7 have largely replaced it. Consider v1 only if you need MAC-address-based uniqueness in a trusted, internal environment.

UUID Version 3: MD5 Name-Based

How It Works

UUID v3 generates a deterministic UUID from a namespace and a name using the MD5 hash algorithm. The same namespace + name always produces the same UUID.

import uuid
# Always produces the same UUID
uuid.uuid3(uuid.NAMESPACE_DNS, "example.com")
# → 9073926b-929f-31c2-abc9-fad77ae3e8eb

Pros

• Deterministic: Same input → same output, every time
• No coordination needed: Two systems independently produce the same UUID for the same input

Cons

• MD5 is cryptographically broken. While this doesn't matter for UUID generation (collision resistance at this scale is fine), it's an optics issue
• V5 is the preferred alternative for name-based UUIDs

When to Use V3

When you need backward compatibility with systems already using v3. For new projects, use v5 instead.

UUID Version 4: Random

How It Works

UUID v4 is the simplest: 122 bits of randomness from a cryptographically secure random number generator (CSPRNG), with 6 bits reserved for version and variant markers.

Example: 550e8400-e29b-41d4-a716-446655440000
                         ^
                    version 4

No timestamp, no MAC address, no determinism. Just random bytes.

Pros

• Maximum privacy: No information about the generator is embedded
• Simple implementation: Just need a good random number generator
• No coordination required: Any system can generate them independently
• Widely supported: The most commonly used version — every language and framework supports it

Cons

• Not sortable: Completely random, so they don't sort by creation time. This matters for database performance (more on that below)
• No embedded metadata: You can't extract a timestamp or origin from the UUID
• Index fragmentation: Random UUIDs cause B-tree index fragmentation in databases, leading to more page splits and slower inserts

When to Use V4

V4 is the safe default for most applications. Use it when:

• You need unique identifiers without any metadata leakage
• Sort order doesn't matter (e.g., API keys, session tokens, correlation IDs)
• You're not using them as primary keys in a high-write database

Generate v4 UUIDs instantly at createuuid.com.

UUID Version 5: SHA-1 Name-Based

How It Works

UUID v5 is the same concept as v3 but uses SHA-1 instead of MD5. Same namespace + name → same UUID, deterministically.

import uuid
uuid.uuid5(uuid.NAMESPACE_URL, "https://example.com")
# → cfbff0d1-9375-5685-968c-48ce8b15ae17

Standard namespaces include:

• NAMESPACE_DNS — for domain names
• NAMESPACE_URL — for URLs
• NAMESPACE_OID — for ISO OIDs
• NAMESPACE_X500 — for X.500 DNs

Pros

• Deterministic: Reproducible from the same inputs
• SHA-1 is stronger than MD5 (though also deprecated for cryptographic use)

Cons

• Still not random — predictable if you know the inputs
• SHA-1 has known weaknesses (though irrelevant at UUID collision scales)

When to Use V5

When you need deterministic UUIDs — turning known data into consistent identifiers. Examples:

• Creating stable IDs for resources based on their canonical URL
• Deduplicating records by generating UUIDs from business keys
• Mapping external identifiers to UUIDs

UUID Version 7: Timestamp + Random (The New Standard)

How It Works

UUID v7 (introduced in RFC 9562, 2024) is the modern answer to UUID design. It combines:

• A 48-bit Unix timestamp in milliseconds (most significant bits)
• 74 bits of randomness
• 6 bits for version and variant

Example: 018f0ecb-a94e-7000-8000-4a4197e8c642
         ^^^^^^^^ ^^^^
         timestamp  version 7

The timestamp occupies the most significant bits, so UUIDs sort chronologically in their standard string or binary representation.

Pros

• Time-sortable: UUIDs generated later are lexicographically greater. This is huge for database performance.
• Database-friendly: No B-tree fragmentation. Inserts are always at the end of the index, like auto-increment integers.
• Still random enough: 74 bits of randomness mean collisions are effectively impossible, even at high generation rates
• Embeds creation time: You can extract the millisecond timestamp
• No privacy leak: Unlike v1, no MAC address or machine identifier is included

Cons

• Newer standard: Not all libraries and databases have native support yet (though adoption is growing fast)
• Millisecond precision: If you generate multiple UUIDs in the same millisecond, the random portion handles uniqueness, but strict monotonic ordering within a millisecond requires implementation-level handling

When to Use V7

This is the version you should use for most new projects, especially if UUIDs serve as database primary keys. The combination of time-sortability and randomness gives you the best of both worlds.

UUID Versions Compared

UUIDs as Database Primary Keys

The Performance Problem with V4

When you use random UUIDs (v4) as primary keys in a B-tree indexed database (PostgreSQL, MySQL), every insert goes to a random position in the index. This causes:

1. Page splits: The database constantly splits index pages to accommodate random insertions
2. Cache misses: The working set of "hot" index pages is the entire index, not just the tail
3. Write amplification: More I/O per insert compared to sequential keys

For tables with millions of rows and high insert rates, this can degrade write performance by 2–10× compared to sequential IDs.

How V7 Solves This

UUID v7's timestamp prefix means new UUIDs are always greater than previous ones (within millisecond precision). Inserts always go to the end of the B-tree, just like auto-increment integers. You get:

• No page splits on insert
• Hot pages stay in cache
• Sequential I/O patterns
• The distributed uniqueness of UUIDs with the performance of sequential IDs

UUID vs Auto-Increment Integer

Generating UUIDs in Different Languages

JavaScript/TypeScript

// V4 (built-in)
crypto.randomUUID();

// V7 (using uuid library)
import { v7 } from 'uuid';
v7(); // → "018f0ecb-a94e-7000-..."

Python

import uuid

uuid.uuid1()  # V1
uuid.uuid3(uuid.NAMESPACE_DNS, "example.com")  # V3
uuid.uuid4()  # V4
uuid.uuid5(uuid.NAMESPACE_DNS, "example.com")  # V5
# V7: use uuid6 library
from uuid6 import uuid7
uuid7()

Go

import "github.com/google/uuid"

id := uuid.New()      // V4
id := uuid.NewV7()    // V7

SQL (PostgreSQL)

-- V4
SELECT gen_random_uuid();

-- V7 (PostgreSQL 17+)
SELECT uuidv7();

For quick generation without code, use our UUID Generator — it supports multiple versions and bulk generation.

Frequently Asked Questions

Can two UUIDs ever be the same?

Theoretically, yes. For UUID v4, the probability of collision after generating 2.71 × 10^18 UUIDs is about 50% (the birthday problem). In practice, you'd need to generate a billion UUIDs per second for 86 years to hit even odds. For all practical purposes, UUID collisions don't happen.

Which UUID version should I use in 2025?

UUID v7 for database primary keys and any context where sort order matters. UUID v4 for tokens, API keys, and identifiers where randomness and privacy are priorities. UUID v5 when you need deterministic IDs from known inputs.

Can I extract the timestamp from a UUID?

From v1 and v7, yes. V1 contains a 60-bit timestamp (100ns intervals since 1582). V7 contains a 48-bit Unix millisecond timestamp. V4 and v5 contain no timestamp information. Our UUID tools can parse and display embedded timestamps.

Are UUIDs secure enough for session tokens?

UUID v4 uses 122 bits of randomness from a CSPRNG, which provides sufficient entropy for session tokens. However, dedicated token formats (like opaque tokens from your auth framework) are preferred because they're designed for the security context and can include additional properties like expiration.

How do UUIDs compare to other ID formats like ULID or nanoid?

ULID (Universally Unique Lexicographically Sortable Identifier) is similar to UUID v7 — timestamp prefix + randomness, but uses Crockford's Base32 encoding instead of hex. Nanoid generates URL-friendly random strings with configurable length. UUID v7 gives you the sortability of ULID with the widespread ecosystem support of UUIDs. Use nanoid when you need shorter, URL-safe identifiers and don't need UUID compatibility.

Need to generate UUIDs quickly? Try our free UUID Generator — create v1, v4, v5, and v7 UUIDs instantly, with bulk generation and format options.