Cryonel

UUID v4 vs v7: Which One Should You Use?

Both give you a 128-bit identifier that's effectively guaranteed unique. The difference is whether that identifier also tells you (and your database) anything about when it was created.

UUID v4 — fully random

Every bit outside the fixed version/variant markers is random. Two v4 UUIDs generated a millisecond apart look completely unrelated — there's no way to tell which came first without external metadata. That's a feature when you specifically don't want to leak creation order or timing (e.g. security tokens, anti-enumeration IDs).

UUID v7 — time-ordered

Defined in RFC 9562 (2024), v7 puts a 48-bit millisecond Unix timestamp in the leading bits, followed by random bits for uniqueness. The practical effect: UUIDs generated later always sort after UUIDs generated earlier, as plain strings/bytes — no separate created_at column needed just to get chronological order.

Why this matters for databases

Using a fully random value (v4, or a random 128-bit string in general) as a primary key or clustered index causes the index to be updated at random locations on every insert, instead of appending to the end. On B-tree-based indexes (used by most relational databases), that means constant page splits and poor cache locality as the table grows — a well-documented performance problem in high-insert-volume tables. Because v7 UUIDs are monotonically increasing, they insert like an auto-incrementing integer would: mostly at the end of the index, with far better locality.

Rule of thumb

Generate one

Cryonel's UUID Generator supports v7, v4, v1, and name-based v3/v5, plus a validator that decodes a UUID's version and embedded timestamp.

Related Tools