UUID v4 vs v7: Which Should You Use for Database IDs?

In the UUID v4 vs v7 choice, the difference is ordering. UUID v4 is almost entirely random. UUID v7 begins with a millisecond timestamp, so IDs created later sort after earlier ones. For new database primary keys, v7 is usually the better choice because it keeps indexes compact. Use v4 when an ID must not reveal when something was created.

Both are 128-bit identifiers written in the same 36-character format, such as 019535d9-3df7-79fb-b466-fa907fa17f9e, and both fit in a standard uuid column. The standard behind them changed in 2024, and that's why v7 is suddenly everywhere. This guide explains what changed, how each version works, and how to choose.

You can create either kind in our free UUID generator, which runs in your browser.

A quick refresher: what is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit value that any system can generate on its own, without asking a central database for the next number. That makes UUIDs useful for:

• primary keys in distributed or multi-tenant systems
• IDs created on a client or mobile device before syncing
• merging data from several databases without clashes
• public IDs in URLs that don't reveal how many customers or orders you have

The format is 32 hex digits in five groups (8-4-4-4-12). The first digit of the third group tells you the version:

019535d9-3df7-7 9fb-b466-fa907fa17f9e   -> version 7
5b30857f-0bfa-4 8b5-ac0b-5c64e28078d1   -> version 4

(Spaces added to highlight the version digit.)

RFC 9562: the new UUID standard

For almost twenty years, UUIDs were defined by RFC 4122. In May 2024 the IETF published RFC 9562, which obsoletes RFC 4122 and adds three new versions: 6, 7 and 8.

RFC 9562 is explicit that implementations "SHOULD utilize UUIDv7 instead of UUIDv1 and UUIDv6 if possible". It also explains why a time-ordered version was needed: random versions such as v4 "have poor database-index locality".

How UUID v4 works

According to RFC 9562 section 5.4, a v4 UUID is 128 bits, of which:

• 4 bits are the version (0100, which is 4)
• 2 bits are the variant
• 122 bits are random

There's no timestamp, no machine identifier and no sequence. Two v4 UUIDs generated a millisecond apart look completely unrelated.

Strengths of v4

• Reveals nothing about when or where it was created.
• Supported everywhere: every language and database can generate one.
• Simple. The only requirement is a good random number generator.

Weaknesses of v4

• New IDs land at random places in a B-tree index, which causes index page splits, poor cache use and bloated indexes on large tables.
• You can't sort by ID to get creation order.

How UUID v7 works

RFC 9562 section 5.7 defines v7 as:

That leaves up to 74 bits for randomness. Because the timestamp comes first, v7 UUIDs sort in roughly the order they were created. Implementations can use the rand_a bits for a counter or sub-millisecond time to keep IDs strictly increasing even when many are generated in the same millisecond.

If you decode the first 48 bits of a v7 UUID, you get its creation time. Paste it into our timestamp converter (as milliseconds) and you'll see when the record was made. Our guide to the Unix timestamp explains the epoch it counts from.

Strengths of v7

• New IDs are appended near the end of the index, much like an auto-increment integer.
• Sorting by ID gives you creation order, which is handy for pagination and debugging.
• The creation time is built in.
• It's still generated independently, with no central sequence.

Weaknesses of v7

• It reveals the creation time to anyone who sees the ID.
• It needs a reasonably accurate system clock.
• Library and database support is newer, although now widespread.

UUID v4 vs v7: side-by-side

Why database index locality matters

Most relational databases (PostgreSQL, MySQL/InnoDB, SQL Server) store primary keys in B-tree indexes. MySQL's InnoDB goes further and stores the table rows themselves in primary-key order.

With an auto-increment integer, every new row goes at the end of the index. The "hot" page is always in memory, and pages fill up neatly.

With random v4 UUIDs, each insert lands somewhere unpredictable. On a small table that's fine. As the table grows beyond memory, inserts touch pages scattered across the whole index. Pages split and end up half-empty, and the database reads from disk more often.

v7 behaves much more like an auto-increment key, because new values are always near the most recent ones. RFC 9562 section 6.11 notes that time-ordered values benefit from greater index locality, and that the real-world performance difference can be an order of magnitude or more. How much you'll see depends on table size, hardware and workload, so test with your own data.

If you're on a small site with a few thousand rows, either choice performs fine. This matters most for tables heading into the millions of rows, and for high write volumes.

Collisions: should you worry?

For practical purposes, no, provided a cryptographically secure random number generator is used.

A v4 UUID has 122 random bits, so there are 2¹²² (about 5.3 × 10³⁶) possible values. Using the standard birthday-problem approximation, you'd need to generate roughly 2.7 quintillion (a little over 2⁶¹) v4 UUIDs before the chance of even one duplicate reached about 50%.

A v7 UUID has fewer random bits, but a collision would also require two IDs to be generated in the same millisecond. Up to 74 random bits per millisecond is still far beyond what any normal application produces.

Real-world duplicate UUIDs almost always come from bugs rather than chance. Typical causes are a weak or badly seeded random generator, virtual machines cloned with identical random state, or code that copies an ID instead of generating a new one. Keep a unique constraint on the column anyway. It costs nothing and catches those bugs.

UUIDs are not secrets

RFC 9562 warns against treating UUIDs as security capabilities. This trips up a lot of small SaaS products:

• A v7 UUID contains its creation time and fewer random bits, so it's partly predictable.
• Even a v4 UUID is an identifier, not a password. It ends up in logs, browser history, referrer headers and analytics.

If a link like /invoice/5b30857f-... should only be visible to the customer, check that the logged-in user is allowed to see that invoice. Don't rely on the ID being hard to guess. For password-reset links or API keys, generate a dedicated random token with a cryptographically secure generator. Our password generator and hash generator are handy for testing.

How to generate v4 and v7 UUIDs

The PostgreSQL 18 documentation lists uuidv7() alongside gen_random_uuid(), plus uuid_extract_timestamp() to read the time back out of a v7 value. Check the docs for your exact language and framework versions, because native v7 support arrived at different times.

Storage tips

• Use a native uuid type (PostgreSQL) or BINARY(16) (MySQL) rather than a 36-character string. It's less than half the size and compares faster.
• In MySQL, if you use UUID_TO_BIN() with the swap flag for v1 UUIDs, don't apply it to v7. v7 is already in the right order.
• Keep v4 and v7 consistent within a table, or the ordering benefit is lost.

When to use which: a decision checklist

1. Building a new table whose primary key is a UUID? Use v7.
2. Will the ID appear publicly, and would revealing the creation time matter? For example, it might expose sign-up dates or order timing. Use v4, or keep a v7 primary key internally and expose a separate random public ID.
3. Need the same ID every time for the same input, such as a URL or email address? Use v5.
4. Existing system already full of v4? There's usually no need to migrate. Consider v7 for new high-volume tables.
5. Need a secret token? Don't use a UUID at all. Use a dedicated random token.

Building a SaaS product? Our free tools for software and SaaS teams collect the generators and decoders developers reach for most. If you'd like help automating the workflows around your product, from onboarding to reporting, Make It Flow is happy to talk it through.

FAQ

What is the difference between UUID v4 and v7?

UUID v4 is made almost entirely of random bits, 122 of them, so the values have no order. UUID v7 starts with a 48-bit Unix timestamp in milliseconds followed by random bits, so values sort by creation time. Both are 128 bits, use the same text format and fit the same database column type.

Is UUID v7 better than v4?

For database primary keys, usually yes. Its time ordering keeps B-tree indexes compact and makes inserts more efficient on large tables, and RFC 9562 recommends time-ordered UUIDs for that reason. v4 is still better when an identifier must not reveal when it was created, or when you need maximum randomness.

Can UUID v7 collide?

In theory, yes. In practice it's vanishingly unlikely. Two v7 UUIDs would have to share the same millisecond and match on up to 74 random bits. Real duplicates almost always come from bugs, such as a poor random number generator or cloned virtual machines, so keep a unique constraint on UUID columns as a safety net.

Does UUID v7 reveal when a record was created?

Yes. The first 48 bits are a Unix timestamp in milliseconds, so anyone who sees the ID can work out the creation time to the millisecond. If that's sensitive, such as customer sign-up dates or order timing, use v4 for public IDs or keep v7 internal only.

What is RFC 9562?

RFC 9562 is the IETF standard for UUIDs, published in May 2024. It replaces RFC 4122, keeps the existing versions, adds versions 6, 7 and 8, and gives guidance on database use. It recommends UUIDv7 over the older time-based versions 1 and 6 where possible.

Should I switch my existing database from v4 to v7?

Usually not for existing data. Changing primary keys is risky and touches every foreign key. A practical approach is to keep existing v4 IDs, use v7 for new tables or high-volume ones such as events and logs, and only migrate if index size or insert speed has become a measurable problem.

Related reading

• Title Case vs Sentence Case: Which Should Your Website Use?: Title case vs sentence case for headings, buttons and SEO titles: what UK style guides like GOV.UK recommend, the rules for each, and how to stay consistent.