UUID v4 vs UUID v7: Which Should You Use?

The Core Difference

v4: 9b2c1f7e-5d3a-4c8b-a1e2-7f6d0c9b3a54   random everywhere except version/variant
v7: 0192f0c1-6a4b-7c3d-9e2f-0a1b2c3d4e5f   first 48 bits = Unix time in ms

What is UUID v4 and what is UUID v7 explain each layout.

Database Performance

Most relational databases store primary keys in B-tree indexes. With v4:

• Each insert goes to a random page, so many pages must stay in memory.
• Pages split frequently, leaving them partly empty.
• On large, write-heavy tables, this shows up as more I/O and bigger indexes.

With v7, inserts behave much like an auto-increment integer: they append near the end, keeping the hot part of the index small. Range queries on recent records can also benefit.

For small tables, the difference is negligible. It grows with table size and write rate. SQL Server has a special consideration: its uniqueidentifier sort order compares the last bytes first, so text-ordered v7 values don't automatically sort chronologically there; see GUID as a primary key.

Privacy and Information Leakage

A v7 ID reveals roughly when it was created. Consequences to consider:

• A public order or user ID can show when an account was created or how activity is distributed.
• IDs created close together share a prefix, which makes the time relationship between records visible.

v4 reveals nothing. A common pattern uses v7 for internal primary keys and v4 (or a separate random token) for anything in public URLs.

Uniqueness

Both are unique for practical purposes. v4 has 122 random bits. v7 has 74 random or counter bits per millisecond, separated by the timestamp, which is still far beyond what any realistic system needs. Implementation quality matters more than the version: use your platform's generator. UUID collision probability covers the maths.

Ordering Caveats

v7 is sortable, but not a perfect sequence. Different machines have slightly different clocks, values from the same millisecond can interleave across generators, and clocks can move backwards. Use a timestamp column or a sequence when exact order matters.

Migration and Compatibility

Switching new IDs from v4 to v7 is usually safe: both are valid UUIDs, so existing columns, validators and APIs accept them. Existing v4 rows stay random; only new rows gain the ordering benefit. Check that any code which parses UUIDs doesn't reject versions other than 4; a strict v4-only regex is a common snag. UUID regex patterns includes version-agnostic options.

Recommendations

• New database primary keys: v7.
• Public, shareable IDs where timing is sensitive: v4.
• Correlation and request IDs: either; v7 makes logs easier to scan by time.
• Existing systems on v4: switch new IDs to v7 if index performance is a problem; otherwise no urgency.

Generating Both

The UUID v7 generator and the UUID v4 generator run in your browser and create up to 1,000 values at a time. Generating a batch of each is a quick way to see the difference: the v7 batch shares an increasing prefix, while the v4 batch is scattered. Paste any v7 value into the UUID decoder to read its timestamp.

A Practical Rollout Plan

If you decide to move from v4 to v7:

1. Audit validation for v4-only regexes or checks and relax them to accept any standard version.
2. Switch generation in one place, ideally a shared ID helper, so every service changes together.
3. Monitor index size and insert latency on your largest tables before and after the change.
4. Document that IDs now encode creation time, so nobody exposes them where that matters.
5. Leave existing data alone; mixed v4 and v7 values coexist without problems.

When to Stay on v4

Staying on v4 is perfectly reasonable when tables are small, writes are infrequent, IDs are mostly public, or your database's clustered key is something else anyway. The benefits of v7 are real but situational; measure before migrating a large system.

Summary

v7 for index-friendly keys, v4 for private, random identifiers. Both are standard, unique and interchangeable in storage, so the choice is about ordering and privacy.