What Is a UUID? v1 vs v4 vs v7 Explained

UUIDs are everywhere. Every AWS resource, every Stripe payment object, every database row in millions of production systems carries one. The format is defined by RFC 4122 (IETF, 2005), updated in 2024 by RFC 9562 (IETF, 2024) which added versions 6, 7, and 8. But most developers just reach for v4 without knowing when a different version would serve them better.

This guide explains what a UUID actually is, breaks down each version’s trade-offs, and tells you exactly which one to use for your specific situation.

developer tools

Generate a UUID Right Now

Use the tool below to generate v1, v4, or v7 UUIDs instantly in your browser. No data leaves your machine.

UUID generator tool

What Is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit value used to identify information without central coordination. RFC 4122 (IETF, 2005) defines the standard format: 32 hexadecimal characters split into five groups separated by hyphens, following an 8-4-4-4-12 pattern. A typical UUID looks like 550e8400-e29b-41d4-a716-446655440000.

Two of those 128 bits are reserved for the variant field (indicating RFC 4122 compliance). Four more bits encode the version number. That leaves either 122 bits of randomness (v4), or a mix of timestamp and random bits (v7), depending on the version you use.

The entire point of the format is generating unique IDs across distributed systems without a central registry or sequence counter. No coordination needed. No network round-trip. Two servers on opposite sides of the planet can each generate millions of UUIDs and never collide.

number systems and hex encoding

Citation capsule: RFC 4122 defines UUID as a 128-bit identifier in 8-4-4-4-12 hexadecimal format (IETF, 2005). RFC 9562 updated the standard in May 2024 to add versions 6, 7, and 8 (IETF, 2024). The format uses 4 bits for version and 2 bits for the variant field, leaving 122 bits available for uniqueness in v4.

Why Do UUIDs Exist?

Auto-incrementing integers break the moment you have more than one database or more than one service generating IDs. Distributed systems need a way to create identifiers independently. UUIDs solve exactly this problem: any node can create a globally unique ID without talking to any other node, with no sequence server, no coordination protocol, and no single point of failure.

The trade-off is size. An auto-increment integer is 4 or 8 bytes. A UUID is 16 bytes as binary, or 36 characters as the canonical hyphenated string. That size difference has real consequences for database index performance, which is why UUID v7 was designed.

What Is UUID v1?

UUID v1 encodes a 60-bit timestamp (nanoseconds since October 15, 1582, the Gregorian calendar reform date) plus the MAC address of the generating machine (RFC 4122, 2005). This makes v1 UUIDs time-sortable by default. Two v1 UUIDs generated on the same machine in sequence will sort correctly by creation time.

The privacy problem is the MAC address. It’s embedded directly in bits 80-127 of the UUID. Anyone who receives a v1 UUID can extract the MAC address of the machine that generated it, identify the network interface vendor, and potentially correlate IDs back to a specific physical machine. This caused real-world privacy concerns when v1 UUIDs appeared in public-facing URLs and log files.

When v1 is still appropriate

v1 remains useful in internal systems where MAC-address leakage doesn’t matter and you want natural time-ordering without extra infrastructure. Some high-throughput event logging systems prefer v1 because events generated in sequence sort correctly with no post-processing. For any externally visible ID, however, v4 or v7 is the better choice.

Citation capsule: UUID v1 embeds a 60-bit timestamp counting 100-nanosecond intervals since October 15, 1582, plus the MAC address of the host machine (RFC 4122, Section 4.1, IETF, 2005). The MAC address occupies bits 80-127 and is recoverable from any v1 UUID, making it unsuitable for externally exposed identifiers.

What Is UUID v4?

UUID v4 is fully random. All 122 non-reserved bits are filled with random data from a cryptographically secure random number generator (RFC 4122, Section 4.4, IETF, 2005). No timestamp. No MAC address. No sequential relationship between IDs. v4 is the most widely implemented UUID version and the default in virtually every language’s standard library.

The collision probability is effectively zero for practical purposes. There are 2^122 possible v4 UUIDs, roughly 5.3 × 10^36 values. If you generated one billion UUIDs per second continuously for 100 years, the probability of a single collision would be approximately 0.000000006% (Wikipedia: UUID, Collision Analysis, citing the birthday paradox calculation). You are astronomically more likely to experience simultaneous hardware failures across every server you own.

The one real problem with v4 in databases

v4 UUIDs are random by design. When used as a primary key in a B-tree database index (PostgreSQL, MySQL, SQL Server), every new row insertion lands at a random position in the index tree. This causes page splits and index fragmentation. Compared to sequential integers, a table with millions of v4 UUID primary keys can see significantly higher write amplification and cache miss rates. Benchmarks vary widely by workload, but the pattern is consistent and well-documented in the PostgreSQL community.

SQL query optimization and indexes

Citation capsule: UUID v4 uses 122 bits of cryptographically random data, yielding approximately 5.3 × 10^36 possible values (RFC 4122, IETF, 2005). Generating one billion UUIDs per second for 100 years produces a collision probability of roughly 6 × 10^-9 percent (Wikipedia: UUID, birthday paradox analysis). For all practical purposes, collisions do not occur.

What Are UUID v3 and v5?

v3 and v5 are name-based versions. They generate a UUID deterministically from a namespace UUID and a name string. The same namespace plus the same name always produces the same UUID. v3 uses MD5 hashing internally; v5 uses SHA-1 (RFC 4122, Section 4.3, IETF, 2005). Prefer v5 over v3 in all new code since MD5 is cryptographically broken (though the collision risk here is theoretical rather than practical for this use case).

What Is UUID v7 and Why Does It Matter for Databases?

UUID v7 is the most significant addition in RFC 9562 (IETF, May 2024). It encodes a 48-bit Unix millisecond timestamp in the most significant bits, followed by 74 bits of random data. Because the timestamp comes first, v7 UUIDs are monotonically increasing over time and sort correctly in any B-tree index. This makes them drop-in replacements for auto-increment primary keys in terms of index performance, while retaining the distributed generation advantage of UUIDs.

The difference in database write performance is meaningful. Sequential inserts into a B-tree index are vastly cheaper than random inserts. Benchmarks from the Supabase team and the CockroachDB project both showed that switching from v4 to a time-ordered UUID format reduced index fragmentation substantially in write-heavy workloads. v7 formalizes this pattern into the official RFC rather than relying on unofficial alternatives like ULID or UUIDv6.

Citation capsule: UUID v7 encodes a 48-bit Unix millisecond timestamp in the most significant bits followed by 74 random bits (RFC 9562, Section 5.7, IETF, 2024). This layout produces monotonically increasing UUIDs that insert sequentially into B-tree indexes, eliminating the page-split fragmentation that makes UUID v4 expensive as a database primary key.

How Do All UUID Versions Compare?

What about v6?

UUID v6 is also new in RFC 9562. It’s a time-ordered rearrangement of v1: the timestamp bits are reordered so the UUID sorts chronologically in a standard lexicographic comparison. But it still embeds a MAC address like v1 does. For new systems, v7 is the better choice since it’s time-ordered and privacy-safe. v6 exists primarily as a migration path for systems already using v1.

UUID vs ULID vs NanoID vs Auto-Increment

UUIDs aren’t the only option. It’s worth knowing when each alternative fits better.

Auto-increment integers (4 or 8 bytes) are the most compact and database-friendly option. Use them when your system is single-node, you don’t merge data across databases, and you don’t expose IDs in URLs (sequential IDs reveal record counts to users). They’re still the default for most web applications.

ULID (Universally Unique Lexicographically Sortable Identifier) is a 128-bit value with a 48-bit millisecond timestamp prefix, formatted as a 26-character Crockford Base32 string. Before UUID v7 was standardized, ULID filled the same niche. It’s slightly more compact in its text representation but is not an IETF standard and has less native support across databases and ORMs.

NanoID generates URL-safe random strings of configurable length. At 21 characters using a 64-character alphabet it has collision probability comparable to UUID v4 (NanoID collision calculator). It’s smaller in text form than a UUID. Use it when you need short, URL-safe IDs and don’t need UUID compatibility with existing systems.

How to Generate UUIDs in Common Languages

Every major language and database has native UUID generation. Here’s the idiomatic approach in each.

Python

import uuid

v4 = uuid.uuid4()           # Random
v5 = uuid.uuid5(uuid.NAMESPACE_URL, "https://example.com")  # Deterministic
print(str(v4))              # '550e8400-e29b-41d4-a716-446655440000'

Python’s standard library uuid module supports v1, v3, v4, and v5. For v7, use the uuid6 package (pip install uuid6) until stdlib support lands.

JavaScript / TypeScript

// Node.js 14.17+ and all modern browsers
const id = crypto.randomUUID();  // UUID v4

// For v7, use the 'uuidv7' package
import { uuidv7 } from "uuidv7";
const id7 = uuidv7();

The Web Crypto API’s crypto.randomUUID() generates v4 in all modern environments. It’s available in browsers, Node.js 14.17+, Deno, Bun, and Cloudflare Workers.

Go

import "github.com/google/uuid"

v4 := uuid.New()                          // v4
v7, err := uuid.NewV7()                   // v7 (uuid v1.6.0+)
v5 := uuid.NewSHA1(uuid.NameSpaceURL, []byte("https://example.com"))  // v5

SQL (PostgreSQL)

-- Built-in v4 (PostgreSQL 13+)
SELECT gen_random_uuid();

-- v7 via pgcrypto extension workaround (until native support)
-- Use uuid-ossp or the pg_uuidv7 extension
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
SELECT uuid_generate_v4();

PostgreSQL’s gen_random_uuid() generates v4. Native v7 support is expected in a future major release. The pg_uuidv7 extension adds v7 generation today.

Frequently Asked Questions

Are UUIDs truly unique? Can two systems generate the same UUID?

For v4, the probability is negligible in all real-world scenarios. With 2^122 possible values, generating one billion UUIDs per second for 100 years gives a collision probability under 6 × 10^-9 percent. In practice, the bigger risk is a broken random number generator. If your system’s CSPRNG is seeded with a predictable value (as has happened with some virtualization environments that share entropy pools across VMs), v4 UUIDs can repeat. Always use a proper CSPRNG and never seed it with time alone.

Should I use UUID as a database primary key?

It depends on your version and workload. UUID v4 as a primary key in a write-heavy B-tree index causes index fragmentation due to random insertion order. UUID v7 solves this by being time-ordered. For read-heavy workloads or smaller tables (under a few million rows), v4 is fine. For write-heavy tables at scale, use v7 or stay with auto-increment integers. Never store UUIDs as VARCHAR — store them as the native UUID type in PostgreSQL, or as BINARY(16) in MySQL, to save storage and improve index performance.

What is the difference between UUID and GUID?

GUID is Microsoft’s term for the same concept. Both follow the RFC 4122 128-bit format with the 8-4-4-4-12 structure. Windows generates GUIDs for COM interfaces, registry keys, and Windows Installer product codes. The underlying format and uniqueness properties are identical. When you see a GUID in a Windows context, treat it as a UUID.

When should I use UUID v5 instead of v4?

Use v5 when you need deterministic ID generation. If the same input should always produce the same UUID (for idempotent operations, cache keys, or deduplication), v5 is the right choice. Given a fixed namespace UUID and a string name, SHA-1(namespace + name) always produces the same 128-bit output. v4 is the right choice when you need a unique ID for a new entity and don’t need to reproduce it from input data.

Does UUID v7 replace ULID?

For practical purposes in new projects, yes. Both solve the same problem: time-ordered, distributed-friendly identifiers with enough randomness to avoid collisions. UUID v7 is now an IETF standard (RFC 9562, 2024), carries the interoperability guarantees that come with that, and is gaining native support in databases and language libraries. ULID has no formal standard body behind it and its text format (Crockford Base32) offers only minor size savings over UUID’s hyphenated hex format. New projects should default to v7.

The Bottom Line

UUID version choice is a small decision with real long-term consequences, especially for databases. For external-facing identifiers and general use, v4 remains the safe, widely supported default. For new database primary keys with write-heavy workloads, switch to v7 — it’s now the official standard and eliminates the index fragmentation problem that made UUID primary keys painful. Use v5 when you need deterministic IDs from stable inputs. Avoid v1 in any externally visible context because of the MAC address leak.

If you need to generate UUIDs right now, the UUID generator tool on this site creates v1, v4, and v7 UUIDs in your browser with zero data leaving your machine.

explore all developer tools