UUID v4 or v7 for Database Primary Keys?
Why random v4 IDs hurt indexes, how v7's timestamp keeps them in order, and when v4 is still right.
By the TurantTools Dev team · Updated October 27, 2026 · 3 min read
Random UUIDs (v4) make poor database primary keys at scale: each new row lands in a random place in the index, so pages split and the cache misses. UUID v7 starts with a timestamp, so new IDs arrive in order, like an auto-increment, while staying globally unique.
| Example | Sorts by creation time? | |
|---|---|---|
| v4 | 33a81d92-077c-4166-9b50-c53aaf24990e | No |
| v7 | 01a17cb1-f5c0-770a-9d30-4356697c8fa2 | Yes |
Decoding the v7 above gives its creation time: 2026-10-27T09:30:00.000Z.
Which to choose
- v7 for primary keys and anything you list in time order: better index locality and natural sorting.
- v4 when the ID mustn't reveal when it was made, such as public share links or invite codes.
- Store UUIDs in a native
uuidor 16-byte binary column, not a 36-character string.