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.

UUID v4 fills all 122 bits of its 128 bits with random data, except for the 6 bits that indicate the version and variant. Since 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 a strength when creating identifiers that must not be guessable, such as tokens embedded in public URLs.

UUID v7 stores a millisecond-resolution 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 sequences produces an order that is nearly identical to the generation order. It preserves the randomness benefits of v4 while also avoiding the problem v1 (MAC address plus time based) had, where information about the generating machine could leak from the ID.

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.

• 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.

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.