UUID v4 vs v7 for Database Primary Keys: Performance, Privacy and Practical Advice

A UUID is a 128 bit value written as 32 hexadecimal digits in groups of 8, 4, 4, 4 and 12. Version 4 fills 122 of those bits with random data, which makes a collision so unlikely that you can ignore it in practice. The guarantee is uniqueness, not secrecy or ordering. A UUID is not a password and is not safe as an access token unless it came from a secure random source and you treat it as a secret.

Most databases store primary keys in a B-tree. When new keys are increasing, new rows are added at the right edge of the tree, which stays in memory and fills pages neatly. Random UUID v4 keys land in random places, so inserts touch pages all over the index. The results are more page splits, more fragmentation, a larger index and more cache misses once the table outgrows memory. On small tables you will never notice. On tables with hundreds of millions of rows, the difference can be large.

Version 7, standardized in RFC 9562 in 2024, starts with a 48 bit Unix timestamp in milliseconds followed by random bits. New values sort roughly in creation order, so inserts append near the end of the index much like an auto increment key, while you keep the benefits of IDs created anywhere without coordination.

• ▸Better insert locality and smaller index growth than v4.
• ▸Sortable by creation time, which also means you can often order by ID instead of keeping another column.
• ▸Ordering is approximate across machines, since it relies on clocks and does not guarantee strict order within the same millisecond.
• ▸The creation time can be read from the ID. If exposing when a record was created is a privacy problem, for example for user accounts, v7 leaks that, while v4 does not.

• ▸Version 1 combines a timestamp with a node identifier that was traditionally the machine's network address. It leaks both time and machine, so avoid it for public IDs.
• ▸Version 3 and 5 are deterministic hashes of a name, useful for creating the same ID from the same input.
• ▸ULID and KSUID are older time ordered designs with their own text formats. They solve the same problem, but UUID v7 has the advantage of fitting the native UUID column type everywhere.
• ▸A plain auto increment integer is still the smallest and fastest choice when one database owns ID creation and exposing the count of records is acceptable.

• ▸Use the native uuid type where it exists, such as PostgreSQL's uuid, which stores 16 bytes. Storing the 36 character text form takes more than twice the space in the table and in every index.
• ▸In MySQL, use BINARY(16) and convert with the built-in functions. Note that a v1 UUID needs the time parts swapped to be index friendly, while v7 is already ordered.
• ▸Make the key type the same everywhere it is referenced, because every foreign key and every secondary index repeats the key.
• ▸Do not use the UUID as a clustered key in engines that cluster on the primary key unless it is time ordered.

• ▸Small system, one database creating IDs: auto increment or v4 are both fine. Choose based on whether you want to expose sequential numbers.
• ▸Large write heavy table, IDs created in several services: v7.
• ▸Public identifiers that must not reveal creation time: v4, or a separate random public ID next to an internal ordered key.
• ▸Anything used as a secret: generate a dedicated token with a secure random generator and store only its hash.

The UUID Generator on this site creates both versions in bulk for fixtures and tests, with options for uppercase, no hyphens and braces.