UUID Versions Explained: A Complete Guide

The ID Collision

Your database has a primary key violation. Two users have the same ID. How is that possible? You were using auto-increment integers.

Then you remember: you merged data from two different systems. Both started counting from 1. User #1 from System A conflicts with User #1 from System B.

This is why distributed systems use UUIDs. They are practically impossible to collide across all systems, all the time.

What is a UUID?

UUID stands for Universally Unique Identifier. It is a 128-bit number represented as 36 characters: 32 hexadecimal digits plus 4 hyphens.

A UUID looks like this: 550e8400-e29b-41d4-a716-446655440000. The format is 8-4-4-4-12 characters.

The chance of generating two identical UUIDs is astronomically low. You would need to generate billions of UUIDs per second for centuries to have a reasonable chance of a collision.

UUID Versions Explained

There are several UUID versions, each with different generation methods:

• Version 1 - Based on timestamp and MAC address. Not recommended for privacy (reveals computer info).
• Version 4 - Completely random. Most common and recommended for general use.
• Version 5 - Based on a namespace and name. Same input always produces same UUID.
• Version 7 - Newest version, combines timestamp and randomness. Good for database indexing.

When to Use UUIDs

UUIDs are ideal for:

• Database primary keys - Especially in distributed systems
• Session identifiers - Track user sessions securely
• API keys - Generate unique access tokens
• File names - Avoid conflicts when merging files from different sources
• Transaction IDs - Track operations across microservices

UUID v7 in 2026: the new default

UUID v7 was standardized in RFC 9562 (May 2024) and has quickly become the default choice for new identifiers that need to be sortable and database-friendly.

Major databases now generate v7 natively (for example, PostgreSQL's uuidv7() in PostgreSQL 18), and popular identifier libraries ship v7 out of the box. Because v7 embeds a millisecond timestamp, values are time-ordered, which reduces B-tree index fragmentation under high insert volume.

Practical guidance: use v7 for primary keys and event IDs where ordering helps performance; use v4 when you need fully unpredictable random values (for example, tokens); avoid v1 for new work because it can leak the generating machine's MAC address.

When NOT to Use UUIDs

UUIDs are not always the best choice:

• Sequential access patterns - UUIDs are random, causing index fragmentation
• Very high write volumes - Random inserts are slower than sequential
• Human-readable IDs - UUIDs are long and hard to remember
• Small datasets - Auto-increment integers are simpler and more efficient

FAQ

References

This article is based on industry standards and best practices from authoritative sources:

• RFC 9562 - Universally Unique IDentifiers (UUIDs): https://www.rfc-editor.org/rfc/rfc9562