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

• Default to v7 for new database primary keys, event IDs, or anything inserted at high volume — you get UUID's collision-resistance without the random-insert performance penalty.
• Use v4 when you deliberately don't want any timing information encoded — e.g., a password-reset token, where an attacker being able to infer "this token was likely issued within the last 5 minutes" from the ID itself is undesirable.

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.

Operational trade-offs

Time ordering improves locality but does not guarantee strict global sequence. Multiple IDs generated in the same millisecond still rely on random or implementation-specific monotonic bits, and clocks can move backward. If business logic needs a total order, store an explicit database sequence or event offset rather than sorting UUIDs alone.

Neither version is an authorization mechanism. A v4 value is difficult to guess, but possession should not grant access without a separate permission check. A v7 value also exposes an approximate creation time, which may be useful for operations but inappropriate for privacy-sensitive public identifiers. Choose based on indexing and disclosure needs, then enforce uniqueness with a database constraint.

Frequently Asked Questions

Related Tools and Guides