A UUID (Universally Unique Identifier) is a 128-bit unique identifier, but many people use one version or another without realizing that versions such as "v4" and "v7" even exist. This article organizes the structural differences between the most widely used v4 and the increasingly popular v7 (often chosen for database primary keys), along with criteria for deciding which one to use.

Structural Differences: Randomness vs. Chronological Order

UUID v4 fills all 122 of its 128 bits with random values, except for the 6 bits that indicate the version and variant. Because there is no relationship between generation order and the magnitude of the value, you cannot tell which of two v4 UUIDs was created first just by comparing them. This complete randomness is what makes v4 strong for building identifiers that are hard to guess, such as tokens used in public URLs.

UUID v7 stores a millisecond-precision UNIX timestamp in its first 48 bits and fills the rest with random bits. Because the timestamp comes first, sorting generated UUIDs in ascending order as raw byte strings produces an order that is nearly identical to the generation order. It keeps the randomness of v4 while also avoiding the problem that v1 (MAC address + time based) had, where information about the generating machine could leak from the ID.

Impact When Used as a Database Primary Key

In RDBMSes that use B-tree indexes (such as MySQL's InnoDB or PostgreSQL), using v4 as the primary key means inserted values are completely random, so new rows get inserted at random positions throughout the index. This causes frequent page splits, lowers cache hit rates, and tends to degrade insert performance. v7, on the other hand, increases monotonically with time, so inserts are always appended near the end of the index, preserving insert performance close to that of a sequential primary key (such as AUTO_INCREMENT). This is why v7 is chosen in cases where a unique ID is needed across a distributed environment, but database performance still matters.

Criteria for Choosing Between Them

  • Choose v4 when no ordering or timing information must ever be inferable from the value itself — for example, session tokens or one-time password-reset URLs.
  • Choose v7 when having values that are nearly sorted by creation order brings a performance or operational benefit — for example, database primary keys, log IDs, or event IDs.
  • Because v7 embeds the creation timestamp directly in its first 48 bits, the ID reveals roughly when it was created. v7 is unsuitable for use cases where the creation time must stay hidden — for example, when you don't want others to infer the order in which records were obtained — and v4 should be used instead.

Related Topic: How ULID Differs

From the perspective of a chronologically sortable ID, ULID is another identifier with characteristics similar to UUID v7. ULID represents its 128 bits as 26 Base32-like characters and, like v7, places a millisecond timestamp at the front — the same design philosophy. If compatibility with the UUID format (the 8-4-4-4-12 hyphenated layout) matters most, choose v7; if a shorter string or interoperability with existing ULID implementations matters more, choose ULID.

If you want to check the difference by looking at actual generated results, you can generate v1, v4, and v7 UUIDs together with the following tool.