ERA OF MINDS

UUID v4 vs v7: which should you use?

By Salman Ahmed, Era of Minds ·

Short answer

Use UUID v7 for database primary keys and anything that benefits from sorting by creation time: it starts with a 48-bit Unix timestamp in milliseconds, so new IDs land next to each other in an index. Use UUID v4 when you want an ID that reveals nothing, since it is 122 random bits. Both are 128 bits and look identical as text apart from the version digit. RFC 9562 notes that random v4 keys have poor database-index locality and that time-ordered inserts can be an order of magnitude or more faster. Generate either with our free UUID generator.

Era of Minds cover: V4 or V7? Pick one. UUID v4 vs v7 comparison table: random bits, time-ordered, sorting, creation time and length, per RFC 9562.
Comparison based on RFC 9562 (May 2024), checked Oct 16, 2026.

What is the difference between UUID v4 and v7?

UUID v4UUID v7
Defined inRFC 9562 section 5.4RFC 9562 section 5.7
Built from122 random bits48-bit Unix time in ms + 74 random (or counter) bits
Sorts by creation timeNoYes, as raw bytes and as text
Database index insertsRandom positionsAppended near the newest values
Reveals when it was madeNoYes, to the millisecond
Size128 bits, 36 characters as text128 bits, 36 characters as text
Example3f2b8c1e-9a4d-4c7e-8b21-6d0e5f7a9c13017f22e2-79b0-7cc3-98c4-dc0c0c07398f

The version is the first digit of the third group: 4 or 7. Both share the same variant bits, and any system that stores UUIDs stores either without changes.

How is a UUID v7 built?

Per RFC 9562, section 5.7, the first 48 bits are the Unix timestamp in milliseconds (big-endian), then 4 version bits set to 7, then 12 bits called rand_a, 2 variant bits, and 62 bits of rand_b. Implementations may use part of the random space for a sub-millisecond fraction or a counter so IDs made in the same millisecond still increase. The RFC says implementations should use v7 instead of v1 and v6 where possible.

The RFC's test vector 017F22E2-79B0-7CC3-98C4-DC0C0C07398F decodes to February 22, 2022, 19:22:22 UTC. Paste it into the decoder on our UUID generator to see.

Is UUID v7 faster than v4 in a database?

For B-tree indexes, usually yes on writes. RFC 9562 section 2.1 says non-time-ordered UUIDs like v4 "have poor database-index locality", forcing inserts at random places, and that the effect on B-trees "can be dramatic". Section 6.11 adds that the real-world difference between time-ordered and random inserts "can be one order of magnitude or more". Your numbers depend on table size, cache and engine, so benchmark your own workload.

Storage is the same either way. The RFC recommends storing UUIDs as 128-bit binary where the database supports it rather than as 36-character text (section 6.13).

When should you still use UUID v4?

  • When creation time is sensitive. Anyone with a v7 ID can read when it was created. If that leaks something (signup dates, order volume), use v4.
  • When order does not matter and the IDs are not hot index keys: file names, request IDs, idempotency keys.
  • When your stack has no v7 generator yet. v4 is everywhere, including crypto.randomUUID() in browsers.

Neither is a password. RFC 9562 section 8 says UUIDs should not be assumed hard to guess and must not be used as security capabilities (IDs whose mere possession grants access).

How do you generate UUID v7 in Postgres, Python and JavaScript?

  • PostgreSQL 18: uuidv7() generates a v7; gen_random_uuid() (also uuidv4()) gives v4.
  • Python 3.14: uuid.uuid7(); uuid.uuid4() for v4.
  • JavaScript: crypto.randomUUID() gives v4 only; for v7 use a library or our generator.

Want an AI agent to wire this into your schema? See the best AI tools for coding.

Key facts

  • Both versions are defined in RFC 9562 (May 2024), which replaced RFC 4122.
  • v4: 122 random bits. v7: 48-bit Unix ms timestamp + random/counter bits.
  • RFC 9562: time-ordered inserts can beat random ones by an order of magnitude or more in index locality.
  • v7 exposes its creation time; v4 does not.
  • RFC 9562 section 8: UUIDs must not be used as security capabilities.
  • PostgreSQL 18 has uuidv7(); Python 3.14 has uuid.uuid7().

FAQ

UUID v4 vs v7: which should I use?

Use v7 for database primary keys and anything that should sort by creation time. Use v4 when the ID must not reveal when it was created. Both are 128-bit UUIDs defined in RFC 9562.

Is UUID v7 better than v4?

For database keys, usually. v7 starts with a millisecond timestamp, so new rows insert near each other in B-tree indexes. RFC 9562 says v4 has poor index locality. v4 is better when you do not want to expose creation time.

Does UUID v7 leak information?

Yes, its creation time to the millisecond, because the first 48 bits are a Unix timestamp. It does not include a MAC address.

Are UUID v4 and v7 the same length?

Yes. Both are 128 bits, written as 36 characters with hyphens. Only the version digit and the meaning of the bits differ.

Can I switch from UUID v4 to v7?

Yes, for new rows. Both fit the same uuid column type, so old v4 and new v7 values can live side by side. Existing v4 values keep their random order.

How do I generate a UUID v7?

Use uuidv7() in PostgreSQL 18, uuid.uuid7() in Python 3.14, a library in JavaScript, or the free Era of Minds UUID generator in your browser.

Sources

Keep reading