UUID v1 vs v4: Which Should You Use?

Compare UUID version 1 (time-based) and UUID version 4 (random). Understand the security, sortability, and uniqueness trade-offs to choose the right UUID type for your use case.

UUID v1 vs v4 Comparison

Both UUID v1 and v4 produce 128-bit identifiers, but they work very differently. The right choice depends on whether you need sortability, privacy, or database performance.

UUID v1 (time-based): Encodes the current timestamp + MAC address — sortable by creation time but leaks machine identity
UUID v4 (random): 122 bits of cryptographic randomness — no timestamp, no machine info, fully opaque
UUID v7 (new standard): Combines time-ordering like v1 with randomness like v4 — ideal for database primary keys

Generate a UUID →

UUID v1 vs v4 Side-by-Side

Format: Both produce the same xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx structure — the M digit indicates version (1 or 4)
Sortable by time: v1 yes (timestamp in first fields), v4 no (random order)
Privacy: v1 embeds MAC address and timestamp — avoid in public-facing IDs; v4 reveals nothing
Uniqueness guarantee: v1 relies on unique MAC + monotonic clock; v4 relies on statistical probability (collision probability is negligible at any realistic scale)
Database index performance: v4's random insertion pattern fragments B-tree indexes; v1 and v7 insert sequentially and perform better for high-insert workloads

When to Use Each Version

Use UUID v4 for most general-purpose IDs: user IDs, session tokens, API keys, resource identifiers in REST APIs — randomness provides privacy and adequate uniqueness
Use UUID v1 when you need temporal ordering and are not exposing IDs publicly (internal distributed systems where MAC address leakage is acceptable)
Use UUID v7 (if your system supports it) for database primary keys — time-ordered randomness solves v1's privacy problem and v4's index fragmentation problem
Avoid UUID v1 in public APIs — the embedded MAC address and timestamp allow attackers to infer when and where an ID was generated

Frequently Asked Questions

Can UUID v4 ever produce a collision?

Theoretically yes, practically no. UUID v4 has 122 bits of randomness, giving 2^122 possible values (~5.3 × 10^36). To have a 50% chance of a collision, you'd need to generate approximately 2.7 × 10^18 UUIDs — far beyond any realistic system. At 1 billion UUIDs per second, reaching that threshold would take ~85 years. For all practical purposes, UUID v4 collisions don't happen.

Why does UUID v4 hurt database performance?

Most databases use B-tree indexes for primary keys. B-trees perform best when new rows insert at the end (sequential IDs). UUID v4's random distribution causes new rows to insert throughout the entire index tree — requiring expensive page splits, increasing index fragmentation, and reducing cache efficiency. The fix is UUID v7 (time-ordered) or using a ULID, both of which maintain monotonic ordering while still being random enough to avoid conflicts.

What's the difference between a UUID and a GUID?

GUID (Globally Unique Identifier) is Microsoft's term for the same concept. UUIDs and GUIDs follow the same RFC 4122 standard and are interchangeable. The term GUID is common in Windows/.NET contexts; UUID is used everywhere else. Both formats are xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.