UUID v1 vs v4 vs v5: Differences Explained

UUID v1: Time and MAC Address Based

UUID v1 uses the current timestamp (precise to 100 nanoseconds) and the node's MAC address to generate the UUID. The timestamp counts from October 15, 1582 (the Gregorian calendar reform date), stored in the time_low, time_mid, and time_hi fields. Because it contains a timestamp, UUID v1 is monotonically increasing (UUIDs generated on the same node are ordered by generation time). This makes v1 excellent for time-sorted scenarios, but creates privacy concerns: the UUID embeds the MAC address, potentially revealing the generating machine's identity.

UUID v4: Fully Random

UUID v4 uses a cryptographically secure random number generator to fill 128 bits, only setting the version field (high 4 bits of the third group = 0100) and variant field (high 2 bits of the fourth group = 10). This means v4 UUIDs have 122 bits of actual randomness. Pros: simple to generate, no privacy leak risk, not dependent on hardware information. Cons: no temporal ordering, causes frequent B-tree index page splits in databases (random inserts reduce performance). v4 is the most widely used UUID version and the default choice for the vast majority of use cases.

UUID v3 and v5: Namespace UUIDs

UUID v3 and v5 are both "namespace UUIDs" — deterministic UUIDs derived from a fixed namespace and a name (same input always produces same output). The difference is the hash algorithm: v3 uses MD5, v5 uses SHA-1. Because MD5 is considered insecure, v5 is preferred. Common uses: generating unique IDs for URLs (same URL always maps to same UUID); generating stable identifiers for DNS names; use in content-addressable storage systems. RFC 4122 predefines several standard namespaces: DNS, URL, OID, X.500.

UUID v7: Next-Generation Sortable UUID

UUID v7 is a new version defined in RFC 9562 (released 2024), combining v1's temporal ordering with v4's randomness: the high 48 bits are a Unix millisecond timestamp, and the low 74 bits are random data (plus version and variant bits). UUID v7 naturally sorts by generation time, does not leak MAC addresses, and is excellent as a database primary key. Compared to v1, v7 has higher time precision (milliseconds), uses Unix timestamps (more intuitive), and supports direct extraction of generation time. More libraries are beginning to support v7 — recommended as a priority over v1 for new projects.

Collision Risk by Version

UUID v1 has the lowest collision risk (theoretically, v1 UUIDs generated on the same node at the same time point are unique; the clock sequence field handles clock rollback); UUID v4 has 122 bits of randomness with extremely low collision probability (among 1 billion UUIDs, the probability of the first collision is about 10^-18); UUID v5 always produces the same output for the same input, so collision between two different (namespace, name) combinations is extremely rare, but same input producing same output is a feature, not a defect. In practice, collision risk for any version is negligible.

How to Choose the Right Version

Selection guidance: general purpose (app IDs, resource IDs) → UUID v4; database primary keys (index performance needed) → UUID v7 (new projects) or ordered UUID solution; deterministic IDs (same input same output) → UUID v5; need to extract generation time from UUID → UUID v7 or v1; privacy requirements (avoid leaking machine info) → avoid v1, choose v4 or v7. Most modern programming language standard libraries already support v4; v7 support is also rapidly spreading across major language libraries.

Code Examples: Generating Each Version

# Python
import uuid

# UUID v1 (基于时间+MAC)
print(uuid.uuid1())

# UUID v4 (随机)
print(uuid.uuid4())

# UUID v5 (命名空间 + 名称)
print(uuid.uuid5(uuid.NAMESPACE_URL, 'https://example.com'))

# UUID v3 (MD5)
print(uuid.uuid3(uuid.NAMESPACE_DNS, 'example.com'))

# Node.js (v4 内置, v7 需要第三方库)
const { randomUUID } = require('crypto');
console.log(randomUUID()); // UUID v4

// uuid npm 包支持所有版本
const { v1, v4, v5, v7 } = require('uuid');
console.log(v7());