Developer Tools2026-03-267 min read|MJMinjae

Why Your UUID v4 Primary Key Is Killing Database Performance — And What v7 Fixes

UUID v4 looks fine in tests but destroys B-tree index performance at scale. UUID v7 fixes it with time-ordered generation. Here's when to use each.

Digital matrix code representing unique identifiers and UUIDs

A team I consulted for had 50 million rows in a PostgreSQL users table using UUID v4 primary keys. Simple SELECT queries that should have been instant were taking 3-4 seconds. The culprit wasn't the query — it was the random UUIDs thrashing the B-tree index cache. Every insert hit a random part of the index, evicting pages that were about to be read. We migrated new rows to UUID v7 (time-ordered) and query latency dropped 85% within a week. Same data, same queries, just ordered keys.

UUIDs solve real problems — distributed generation, URL-safe IDs, no coordination between services. But the version matters more than people realize. v1 leaks your MAC address. v4 kills index performance. v7, finalized in RFC 9562 in 2024, fixes both while keeping the uniqueness guarantees. If you're starting a new project in 2026 and still reaching for uuid.v4(), this guide will change your mind.

What you'll learn in this guide

✅Why UUID v4 primary keys slow down as your table grows past ~10 million rows
✅How UUID v7 combines time-ordering with the anti-coordination benefits of v4
✅Concrete rules for picking v1, v4, v7 — or falling back to auto-increment

What Is a UUID?

A UUID is a 128-bit identifier that is unique across all space and time. It's represented as 32 hexadecimal digits displayed in 5 groups separated by hyphens: 550e8400-e29b-41d4-a716-446655440000. The key property is that UUIDs can be generated independently by any system without coordination, yet remain virtually guaranteed to be unique.

128 bits = 2^128 possible values (340 undecillion)
Format: 8-4-4-4-12 hexadecimal digits
No central authority needed for generation
Standardized by RFC 4122 (and RFC 9562 for v7)
Also known as GUID (Microsoft terminology)

Try this tool now:

Try Our UUID Generator →

UUID Versions Explained

Not all UUIDs are created equal. Each version uses a different strategy for generating unique values, with different trade-offs.

UUID v1 — Timestamp + MAC Address

v1 combines a timestamp with the machine's MAC address. This guarantees uniqueness but leaks information about when and where the UUID was generated — a privacy concern in some applications.

Pros: Time-ordered, guaranteed unique per machine
Cons: Leaks timestamp and MAC address, privacy risk
Use when: Internal systems where privacy isn't a concern

UUID v4 — Random

v4 is the most popular version. It uses 122 bits of random data (6 bits reserved for version/variant). Simple, widely supported, and reveals nothing about generation time or source.

Pros: Simple, no information leakage, universally supported
Cons: Not time-ordered (poor B-tree index performance), fully random
Use when: General purpose, when you need a quick unique ID
Collision probability: 1 in 2.71 quintillion for any pair

UUID v7 — Time-Ordered Random (Recommended)

v7 is the newest standard (RFC 9562, 2024). It embeds a Unix timestamp in the first 48 bits, followed by random data. This makes v7 UUIDs naturally sortable by creation time — a huge advantage for database indexes.

Pros: Time-ordered, great DB index performance, no information leakage
Cons: Newer standard, not yet universally supported in all libraries
Use when: Database primary keys, event IDs, anything that benefits from ordering
Recommendation: v7 is the best choice for new projects in 2026

UUID vs Auto-Increment ID

Auto-increment: Sequential, compact (4-8 bytes), but reveals record count and creation order
UUID: 16 bytes, non-sequential (v4) or time-ordered (v7), reveals nothing about your data
UUID advantage: No coordination needed in distributed systems, safe to expose in URLs
Auto-increment advantage: Smaller storage, faster joins, simpler to read
Hybrid approach: Use auto-increment internally, UUID for external-facing identifiers

Practical Applications

Database primary keys: v7 for ordered inserts, v4 for random access
API request IDs: Track requests across microservices
Session tokens: Unique, unpredictable session identifiers
File naming: Prevent collisions in distributed file storage
Idempotency keys: Ensure API operations execute exactly once
Event sourcing: Unique event identifiers in event-driven architectures

💡

Default to UUID v7 for new projects in 2026

Unless you have a specific reason not to, use v7. You get the distributed-generation benefits of v4 (no coordination, no central authority), the index performance of auto-increment IDs (time-ordered), and no privacy leak from v1's MAC address. Most modern libraries — Node crypto.randomUUID with v7 polyfill, Python's uuid7 package, PostgreSQL 18's native uuid_generate_v7() — all support it. The only reason to stick with v4 is if you're on a stack that hasn't caught up yet.

⚠️

Never use UUIDs for security tokens

UUID v4 provides 122 bits of randomness, but it's not designed for cryptographic security. Some libraries use non-cryptographic PRNGs that make UUIDs predictable if an attacker sees enough samples. For API keys, session tokens, or password reset links, use dedicated cryptographic random generators (crypto.randomBytes in Node, secrets module in Python) that give you at least 256 bits of entropy. UUIDs are unique IDs, not secrets.

UUID Generator

Generate v1, v4, or v7 UUIDs in bulk, copy as string, binary, or array format

Generate UUIDs →

Frequently Asked Questions

Can UUIDs collide?

Theoretically yes, but practically no. With UUID v4, you'd need to generate 2.71 quintillion UUIDs to have a 50% chance of a single collision. Most systems will never encounter a collision.

Are UUIDs secure enough for tokens?

UUID v4 provides 122 bits of randomness, which is sufficient for many use cases. However, for security-critical tokens (API keys, password reset links), use a dedicated cryptographic random generator with at least 256 bits.

How much storage does a UUID use?

As a string: 36 bytes (with hyphens) or 32 bytes (without). As binary: 16 bytes. Most databases have native UUID types that store them as 16-byte binary values efficiently.

Should I use UUID or ULID?

ULID (Universally Unique Lexicographically Sortable Identifier) is similar to UUID v7 — both are time-ordered. UUID v7 is now an official RFC standard, making it the more standardized choice. Use UUID v7 for new projects.

Can I extract the timestamp from a UUID v7?

Yes! The first 48 bits of a UUID v7 contain a Unix timestamp in milliseconds. This can be useful for debugging and audit trails without needing separate created_at columns.