UUID v4 is the default choice for most developers. But UUID v7 exists for a reason — and if you're using UUIDs as database primary keys, the difference matters significantly.
What's the difference?
UUID v4 is 128 bits of cryptographically random data. There is no structure to it — every UUID is completely random, independent of when it was generated.
``
4b9b7e2f-1234-4a1b-8abc-9876543210ab ← v4 (random)
01961f2f-0000-7abc-8def-123456789abc ← v7 (timestamp-prefixed)
`
UUID v7 embeds a 48-bit Unix millisecond timestamp in the most significant bits, followed by random bits. UUIDs generated later sort higher — both lexicographically and as raw bytes.
Why does sortability matter for databases?
Most databases use B-tree indexes for primary keys. B-trees store keys in sorted order and expect new inserts to go near the right end of the tree (append pattern).
UUID v4 breaks this assumption. Because every new v4 UUID lands at a random position in the sorted index, inserts trigger random page splits — the database has to reorganise pages to insert the new key at an arbitrary location. At scale, this causes:
- Increased write amplification
- Higher I/O on random disk sectors
- Page fragmentation leading to bloated indexes
- Slower query performance over time
UUID v7 restores sequential inserts. Because newer UUIDs sort after older ones, inserts mostly append to the right end of the index. This is the same pattern as auto-increment integers — predictable, cache-friendly, and efficient.
PostgreSQL, MySQL, and SQL Server all perform significantly better with time-ordered UUIDs for primary keys. At the scale of millions of rows, the difference is measurable.
When to use v4
UUID v4 is still the right choice in many situations:
- Session tokens and API keys — randomness is a security property here, not a bug
- Non-primary-key uses — UUIDs in columns that aren't indexed heavily
- Legacy systems — existing v4 UUIDs in a schema you're not migrating
- Simplest possible setup — v4 is available everywhere; v7 may require a newer library version
UUID v7 support in 2026
v7 was standardised in RFC 9562 (April 2024). Language and framework support is growing fast:
| Platform | v7 support |
|---|---|
| PostgreSQL | gen_random_uuid() → v4. Use uuid_generate_v7() with extension, or pgcrypto |
| MySQL 8+ | Native UUID() → v1. v7 via application layer |
| Node.js | uuid package v9+: import { v7 as uuidv7 } from 'uuid' |
| Python | uuid7 package: pip install uuid7 |
| Java | Java 17+ has UUID, v7 via library (e.g. fasterxml.uuid) |
| Go | google/uuid v1.4+: uuid.New7()` |
Check your ORM's version — Hibernate, Prisma, and Sequelize are adding v7 support as the RFC becomes the standard.
Quick rule of thumb
If it's a database primary key → use v7.
If it's a token, nonce, or external-facing identifier → use v4.
If it's in a URL and length matters → consider NanoID instead.
To generate UUIDs instantly in your browser (for test data, database seeding, or API mocking), SnappyTools UUID Generator generates v4 UUIDs in bulk — up to 100 at a time, with one-click copy.
Originally published at https://snappytools.app/uuid-generator/
