UUID v4 vs v7 vs v1 — Which Version to Use and When (Developer Guide)

UUID Version Comparison — Quick Reference

Version	Based On	Sortable?	Unique Across Systems?	Best For
v1	Timestamp + MAC address	Partially	Yes	Avoid — leaks hardware info
v4	Random	No	Statistically yes	General purpose — most common
v5	Namespace + name (SHA-1)	No	Deterministic	Reproducible IDs from known inputs
v7	Timestamp + random	Yes — time-ordered	Yes	Database primary keys — best performance

The short answer: Use v4 when you need a unique ID and do not care about ordering. Use v7 when the UUID will be a database primary key — it is time-sorted, which dramatically improves insert performance on B-tree indexes.

Why v7 Is Better for Databases (And It's Not Close)

Random UUIDs (v4) cause a well-known database performance problem: index fragmentation.

B-tree indexes (used by PostgreSQL, MySQL, SQLite) keep data sorted. When you insert a random v4 UUID, it lands at a random position in the index — forcing the database to reorganize pages constantly. As the table grows to millions of rows, insert performance degrades.

UUID v7 embeds the creation timestamp in the first 48 bits. New UUIDs are always larger than previous ones — inserts always go at the end of the index. No fragmentation, no page splits, consistent performance even at billions of rows.

Real-world impact: Switching from v4 to v7 as a primary key can improve insert throughput by 2-5× on large tables. The improvement grows as the table grows.

GUID vs UUID — Is There a Difference?

Functionally, no. GUID (Globally Unique Identifier) is Microsoft's term. UUID (Universally Unique Identifier) is the RFC 4122 standard. They use the same format: 550e8400-e29b-41d4-a716-446655440000 — 32 hex characters in 8-4-4-4-12 groups.

The only practical difference: Microsoft's GUID generation in .NET uses a variant of v4 with slightly different byte ordering. For all practical purposes, treat them as identical. The UUID Generator produces standard RFC-compliant UUIDs.

Generating UUIDs in Bulk

Need 100 UUIDs for a database seed script? Setting up test data? The UUID Generator supports bulk generation — specify how many you need and copy the list.

For programmatic generation in your code:

• JavaScript: crypto.randomUUID() — built into modern browsers and Node.js 19+
• Python: import uuid; uuid.uuid4()
• PostgreSQL: gen_random_uuid() — built-in since PostgreSQL 13
• MySQL: UUID() — generates v1 (consider using application-level v4 or v7 instead)

For browser-based bulk generation without writing code, the web tool is faster than setting up a script.

Common Mistakes With UUIDs

• Using v1 in production — v1 UUIDs contain your machine's MAC address, which is a privacy and security leak. Use v4 or v7 instead.
• Storing as strings — UUIDs stored as VARCHAR(36) use 36 bytes. Stored as a native UUID type (PostgreSQL) or BINARY(16), they use 16 bytes — less than half the storage and much faster to index.
• Comparing as strings — string comparison of UUIDs is slower than binary comparison. Use your database's native UUID type when available.
• Using sequential IDs instead — auto-increment IDs leak information (your competitor can guess how many users you have). UUIDs are unpredictable. The tradeoff is size (16 bytes vs 4-8 bytes for integers).