UUID v1, v4, v5, v7 Compared — Which Version Should You Actually Use?

Not all UUIDs are created equal

The UUID specification defines several versions, each generated differently and suited to different use cases. Most developers reach for UUID v4 by default — and for most purposes, that's the right call. But understanding the other versions reveals genuinely useful alternatives, particularly now that UUID v7 is gaining adoption as the recommended version for database primary keys.

UUID basics

A UUID (Universally Unique Identifier) is a 128-bit value represented as 32 hexadecimal characters in a hyphenated format:

550e8400-e29b-41d4-a716-446655440000
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

The M position indicates the version. The N position indicates the variant (for RFC 4122 UUIDs, this is 8, 9, a, or b).

There are currently 8 defined UUID versions. The ones that matter in practice are v1, v3, v4, v5, and v7.

UUID v4: the random one (and the default)

How it's generated: 122 bits of cryptographically random data, plus 6 bits reserved for version and variant.

Uniqueness: probabilistic. The chance of generating a duplicate is astronomically small — you'd need to generate roughly 2.7 × 10¹⁸ UUIDs before a 50% chance of collision. For any real application, treat it as guaranteed unique.

The problem with v4 for database primary keys: random. Every new v4 UUID is unpredictable and non-sequential. In a B-tree index (which is what most databases use for primary keys), inserting random values causes constant page splits and fragmentation. At scale, this means:

• Index becomes fragmented and larger than necessary
• Insert performance degrades
• Cache hit rates drop because new insertions scatter across the entire index rather than appending to the end

For low-to-moderate volume, this is barely noticeable. For high-volume systems inserting thousands of records per second, the performance impact is real.

When to use v4: any unique identifier that doesn't need to be sortable or time-correlated. Session tokens, API keys, reference numbers, anything generated client-side.

UUID v1: the time-based one (and the privacy problem)

How it's generated: current timestamp (100-nanosecond intervals since October 15, 1582) combined with a clock sequence and the MAC address of the generating machine.

Uniqueness: guaranteed within a single machine within the timestamp resolution. The combination of time + machine address + clock sequence makes collisions essentially impossible.

The problem: it embeds the MAC address of the server that generated it. This leaks infrastructure information — anyone with a v1 UUID can extract the MAC address and timestamp of the generating machine. This was how a v1 UUID was used to identify the creator of the Melissa virus in 1999.

The second problem: while v1 UUIDs contain a timestamp, they're not lexicographically sortable in time order because the timestamp is encoded in a split, shuffled format.

When to use v1: legacy systems that still use it. New projects shouldn't generate v1 UUIDs.

UUID v3 and v5: the deterministic ones

How they're generated: a hash of a namespace UUID plus a name string. v3 uses MD5; v5 uses SHA-1. Given the same namespace and name, they always produce the same UUID.

Uniqueness: within a namespace, unique to the name. Two different names will produce different UUIDs (with extremely high probability). The same name always produces the same UUID.

When deterministic UUIDs are useful:

• Deduplication: generating an ID for a URL, email address, or any string such that the same string always produces the same UUID. Enables idempotent operations — if a record with this UUID already exists, it's a duplicate.
• Content-addressable storage: the UUID is derived from the content, so identical content has identical IDs.
• Stable identifiers for migrated data: migrating records from a system without UUIDs to one that requires them, using a deterministic hash of the original ID.

Standard namespaces (use these as the namespace input):

• DNS namespace: 6ba7b810-9dad-11d1-80b4-00c04fd430c8
• URL namespace: 6ba7b811-9dad-11d1-80b4-00c04fd430c8
• OID namespace: 6ba7b812-9dad-11d1-80b4-00c04fd430c8

Example: UUID v5 for https://example.com in the URL namespace:

import uuid
result = uuid.uuid5(uuid.NAMESPACE_URL, "https://example.com")
# Always produces: c7b8c6d8-cce5-5d7f-b5a0-5b5ed9e2e7f2

v3 vs v5: v5 is preferred because SHA-1 is more collision-resistant than MD5. Neither should be used for security purposes (password hashing, etc.) — use bcrypt/Argon2 for that.

UUID v7: the new sortable random one (recommended for database keys)

How it's generated: 48 bits of Unix timestamp (millisecond precision) followed by 74 bits of random data, with 6 bits for version and variant. Standardised in RFC 9562 (2024).

Uniqueness: combines the near-guaranteed uniqueness of random bits with timestamp-based ordering.

Why it solves the v4 database problem: v7 UUIDs are lexicographically sortable by creation time. New records insert at the end of the B-tree index rather than scattering throughout it, preserving index locality and insert performance. They behave much like auto-incrementing integers in terms of index performance, while retaining the distribution benefits of UUIDs.

Comparison of ID types for database primary keys:

When to use v7: new database primary keys in any system where you want globally unique, non-predictable IDs with good index performance. If you're starting a new project in 2024, v7 is the recommendation for most primary key use cases.

One caveat: v7 embeds a timestamp, which means the creation time of a record is recoverable from its ID. For most applications this is fine or even useful. If creation time must be hidden, v4 is more appropriate.

ULID: the pre-v7 alternative worth knowing

Before UUID v7 was standardised, ULID (Universally Unique Lexicographically Sortable Identifier) was widely adopted as a time-ordered alternative to UUID v4. Like v7, it's 128 bits, time-ordered, and random. It uses a different encoding (Crockford Base32 rather than hex) that produces a 26-character string without hyphens: 01ARZ3NDEKTSV4RRFFQ69G5FAV.

If you're working with systems that already use ULIDs, they're a solid choice. For new projects, UUID v7 is the standards-backed option.

How to use the UUID Generator on sadiqbd.com

1. Select the version — v4 for general use, v7 for database keys, v5 for deterministic IDs
2. For v5: enter the namespace UUID and the name string
3. Set the quantity — generate one or in bulk
4. Copy — paste directly into your application, database seed, or test fixture

Frequently Asked Questions

Should I use UUID v4 or v7 for database primary keys? v7 if your database and ORM support it. It provides the same uniqueness guarantees as v4 with significantly better index performance at scale. PostgreSQL 17+ has native UUID v7 support. For most frameworks, UUID v7 libraries are available and well-maintained.

Can I use UUID v5 for user IDs? Yes, if user IDs are derived from something stable like an email address in a specific namespace. The determinism means you can regenerate the UUID from the source data, which is useful for migration and deduplication. The tradeoff: if the source data (email) changes, the UUID changes.

What's the difference between a UUID and a GUID? GUID (Globally Unique Identifier) is Microsoft's term for the same concept. They use the same format and are interchangeable for practical purposes.

Why does UUID use hyphens? The hyphens separate the UUID into its component fields (time-low, time-mid, time-high-version, clock-seq, node) for readability. They carry no data — 550e8400e29b41d4a716446655440000 and 550e8400-e29b-41d4-a716-446655440000 are the same UUID.

Is the UUID Generator free? Yes — completely free, no sign-up required.

UUID v4 remains the right default for most use cases. But knowing when v5 (deterministic) or v7 (sortable, database-friendly) is the better fit makes a real difference in systems that generate IDs at volume or need stable, reproducible identifiers.

Try the UUID Generator free at sadiqbd.com — generate v4, v5, or v7 UUIDs instantly, individually or in bulk.