UUID v4 vs v7: random or time-ordered
v4 is random. v7 embeds a millisecond timestamp. Choose v7 for indexes, v4 when create time must stay hidden.
v4 fills almost the whole 128 bits with random data. Inserts into a B-tree scatter. That is fine for small tables and for IDs you print on receipts.
v7 prefixes a timestamp. New rows land near each other on disk. That helps write-heavy primary keys. The tradeoff is that anyone with the ID can guess when it was minted.
Both are 36-character strings. You can store mixed versions in one UUID column. Generate both in the studio and look at the third group: 4 vs 7.
Choose v4 when the id must not reveal when it was created. Choose v7 when a database index should follow creation order and you accept that the time is public. Both are 128 bits and both can be primary keys. v4 does not sort. v7 sorts until the clock jumps. The generator can emit either; this page is only the choice.
| Trait | UUID v4 | UUID v7 |
|---|---|---|
| Time-sortable | No — random inserts scatter | Yes — Unix ms prefix |
| Leaks create time | No | Anyone with the ID can guess when it was minted |
| Best for | Public IDs, receipts | DB primary keys, write-heavy indexes |
FAQ
Default for a new API?
v7 if the ID is internal. v4 if the ID is public and must not sort by time.
Compatible with GUID?
Yes. Same layout, different version nibble.