Will UUIDs ever collide?

UUIDv4 has 122 random bits, giving 5.3×10³⁶ possible values. You'd need to generate 2.71 quintillion (2.71×10¹⁸) UUIDs to have a 50% chance of a single collision. At 1 billion UUIDs per second, that would take 86 years. In practice, UUID collisions are so unlikely they can be treated as impossible for any real-world application.

What is the difference between UUID and GUID?

They're the same thing. UUID (Universally Unique Identifier) is the standard name defined in RFC 9562. GUID (Globally Unique Identifier) is Microsoft's term for the same concept. The format, structure, and generation algorithms are identical. Use 'UUID' in cross-platform contexts and 'GUID' when working specifically with Microsoft technologies.

Should I use UUIDv4 or UUIDv7?

Use UUIDv7 for database primary keys — its time-ordered prefix ensures sequential inserts perform well with B-tree indexes. Use UUIDv4 for general unique identifiers where sort order doesn't matter (tokens, correlation IDs, session IDs). UUIDv7 is the recommended choice for new applications as of RFC 9562 (2024).

Do UUIDs hurt database performance?

Random UUIDs (v4) as primary keys cause B-tree index fragmentation because inserts happen at random positions. This can reduce write performance by 2-5× compared to sequential IDs on large tables. UUIDv7 solves this by being time-ordered — inserts happen sequentially, performing nearly as well as auto-increment integers.

How many bytes does a UUID use?

A UUID is 128 bits (16 bytes) in binary form. The string representation (e.g., '550e8400-e29b-41d4-a716-446655440000') uses 36 characters (32 hex digits + 4 hyphens). Store UUIDs as binary(16) in databases for efficiency — it's half the storage of the string form and faster to index.

UUID Guide: Versions, Collisions & When to Use Which Format

Developer 11 min read April 2026

UUIDs (Universally Unique Identifiers) are 128-bit values used to identify resources without a central authority. With 5.3×10³⁶ possible values, the chance of collision is effectively zero. But not all UUID versions are created equal — choosing the right one matters for performance, security, and sortability.

UUID Format

A UUID is a 128-bit value displayed as 32 hexadecimal digits in five groups separated by hyphens:

550e8400-e29b-41d4-a716-446655440000

The 13th character (first digit of the third group) indicates the version (4 in this case)
The 17th character (first digit of the fourth group) indicates the variant (8, 9, a, or b for RFC 9562)

UUID Versions Compared

Version	Source	Sortable	Privacy	Use Case
v1	Timestamp + MAC address	Partially	❌ Leaks MAC	Legacy systems (avoid in new code)
v3	MD5 hash of namespace + name	No	✅	Deterministic IDs from names
v4	Random (122 bits)	No	✅	General purpose (most popular)
v5	SHA-1 hash of namespace + name	No	✅	Deterministic IDs (prefer over v3)
v7	Unix timestamp + random	✅ Yes	✅	Database PKs (recommended)

UUIDv4: The Random Standard

UUIDv4 generates 122 bits of cryptographically random data (6 bits are reserved for version and variant):

5.3 × 10³⁶ possible values
No timestamp, no MAC address, no sequence — pure randomness
Supported natively in every major language and database
Ideal for tokens, session IDs, correlation IDs, and any non-sortable identifier

UUIDv7: The New Recommended Standard

Defined in RFC 9562 (2024), UUIDv7 combines a 48-bit Unix timestamp (millisecond precision) with 74 bits of randomness:

Time-ordered: UUIDs generated later are lexicographically greater
Database-friendly: Sequential inserts don't fragment B-tree indexes
Timestamp extractable: You can recover the creation time from the UUID
Still unique: 74 random bits provide 1.9 × 10²² unique values per millisecond

💡 Recommendation: For new applications, use UUIDv7 as your default. It provides the uniqueness of UUIDv4 with the performance benefits of sequential identifiers. Fall back to UUIDv4 only when you specifically need non-time-correlated randomness.

UUID Collision Probability

For UUIDv4 with 122 random bits (birthday problem):

UUIDs Generated	Collision Probability
1 billion (10⁹)	~1 in 10¹⁹ (0.00000000000000001%)
1 trillion (10¹²)	~1 in 10¹³
1 quadrillion (10¹⁵)	~1 in 10⁷
2.71 × 10¹⁸	50% (this is 86 years at 1B/second)

UUID vs. Auto-Increment IDs

Factor	UUID	Auto-Increment
Uniqueness scope	Global (no coordination needed)	Single database table
Storage size	16 bytes (binary)	4-8 bytes
Index performance	v4: poor (random), v7: good (sorted)	Excellent (sequential)
Security	Non-guessable	Sequential (enumerable)
Distributed systems	Works without coordination	Requires sequence server
Merge/migration	No conflict risk	Requires re-numbering

Database Storage Tips

Store as BINARY(16), not VARCHAR(36) — saves 20 bytes per row and indexes 2× faster
PostgreSQL: Use the native uuid type (stored as 16 bytes internally)
MySQL: Use BINARY(16) with UUID_TO_BIN() and BIN_TO_UUID()
Use UUIDv7 for primary keys to maintain index locality

Frequently Asked Questions

You'd need to generate 2.71 quintillion UUIDs to have a 50% chance of a single collision. At 1 billion per second, that's 86 years. UUID collisions can be treated as impossible in practice.

They're the same thing. UUID is the standard name (RFC 9562). GUID is Microsoft's term. Format and algorithms are identical.

Use UUIDv7 for database primary keys (time-ordered, index-friendly). Use UUIDv4 for tokens and IDs where sort order doesn't matter. UUIDv7 is recommended for new applications.

Random UUIDs (v4) cause B-tree fragmentation, reducing write performance 2-5×. UUIDv7 solves this with time-ordering, performing nearly as well as auto-increment.

16 bytes in binary form. The string representation uses 36 characters. Store as binary(16) in databases for half the storage and faster indexing.

Generate UUIDs

Open UUID Generator →