UUID v4 vs v7: Which Should You Use for Database IDs?
How UUIDs work, why random v4 IDs hurt database performance at scale, and why time-ordered UUID v7 is now the recommended choice for primary keys.
Editorial disclosure: Pyalm publishes and maintains the products and free tools discussed on this site. Regulatory statements are linked to primary sources where applicable. No independent professional review is claimed unless a reviewer is explicitly named.
A UUID (universally unique identifier) is a 128-bit ID like 0192f1c4-8e5a-7b3d-9c41-6a2f0e8d1b57. It can be generated anywhere — a phone with no signal, a browser, any server — without asking a central database for the next number, and the chance of two ever colliding is negligible.
Why use UUIDs at all?
- Offline and distributed systems. Apps that create records offline (POS terminals, field apps) need IDs before they sync.
- No guessable IDs.
/invoice/1043invites someone to try/invoice/1044; a UUID doesn't. (You still need proper access checks.) - Merging data. Records from several databases or tenants never clash.
The anatomy of a UUID
32 hex digits in five groups (8-4-4-4-12). The first digit of the third group is the version; the first digit of the fourth group encodes the variant. Paste any UUID into the free UUID Generator to see both.
Version 4: fully random
122 random bits. Simple, universal, supported everywhere (crypto.randomUUID() in every modern browser). The downside appears in databases: random IDs are inserted all over a B-tree index instead of at the end, causing page splits, poor cache use and bloated indexes on large tables.
Version 7: time-ordered
Standardised in RFC 9562 (2024), v7 puts a 48-bit Unix millisecond timestamp first, followed by random bits:
| Property | v4 | v7 |
|---|---|---|
| Unique without coordination | ✓ | ✓ |
| Sorts by creation time | ✗ | ✓ |
| Index-friendly inserts | ✗ | ✓ |
| Reveals creation time | No | Yes (to the millisecond) |
New v7 IDs always sort after older ones, so inserts land at the end of the index like an auto-increment column — while keeping all the benefits of UUIDs.
Which should you choose?
- Primary keys and event IDs: UUID v7.
- Tokens, file names, anything where revealing creation time matters: v4 — or better, a dedicated random token.
- Never use UUIDs as secrets (password-reset or API tokens). Use the Password Generator style of high-entropy random strings instead.
Generating UUIDs
The free UUID Generator creates v4 or v7 IDs in bulk (up to 1,000), with uppercase, no-hyphen and brace options, using your browser's cryptographically secure random generator. It also validates UUIDs and reads the timestamp out of v7 (and v1) IDs.
Storage tips
- Store UUIDs in a native
uuidcolumn (PostgreSQL) orBINARY(16)(MySQL), not as 36-character text. - PostgreSQL 18 includes
uuidv7()natively; older versions can generate v7 in the application. - Keep the canonical lowercase hyphenated form in APIs.
How we use them
Pyalm's offline-first apps — like the Pyalm Books Android app and our POS — generate time-ordered IDs on the device so records can be created offline and synced later without conflicts. If you need an app that keeps working without a connection, see our mobile app development and custom software services.
Related free tools
UUID Generator | Hash Generator | Password Generator | Fake Data Generator | All free tools