UUID v1 vs UUID v4 vs UUID v7 explained

May 11, 2026 · 16 min read

Picking a UUID version is not a style preference. It changes index locality, predictability, privacy, and how painful your database maintenance becomes three years later. This guide compares the three versions you will actually see in production logs in 2026: v1, v4, and v7.

Quick pick guide

New greenfield API, default choice: UUID v7 (time-ordered, random tail).
Need maximum obscurity, no time signal: UUID v4.
Legacy integration only: UUID v1 - avoid for new public IDs.

UUID v1: timestamp + node

Version 1 embeds a 60-bit timestamp (100-ns intervals since UUID epoch), clock sequence, and often a MAC-derived node field. IDs from the same machine cluster in time, which helps debugging but leaks deployment topology.

Pros: naturally sortable by creation time (roughly). Cons: privacy, predictability, obsolete hardware assumptions.

Security reviews sometimes flag v1 because knowing one ID and the clock can narrow guesses for nearby IDs. If you inherit v1 in a legacy CRM, do not rip it out without a migration plan - but do not choose v1 for new customer-facing resources.

v1 example (version digit 1 in third group):
6ba7b810-9dad-11d1-80b4-00c04fd430c8
              ^ version nibble

UUID v4: random

Version 4 sets 122 random bits (with fixed version/variant nibbles). This is what uuid_generate() in many libraries produces by default. Collisions are negligible; index locality in B-trees is poor because inserts land randomly across the key space.

// Node.js crypto.randomUUID() -> RFC 4122 v4
const id = crypto.randomUUID();
// "f47ac10b-58cc-4372-a567-0e02b2c3d479"

UUID v7: time-ordered random

UUID v7 (standardized in RFC 9562) places a 48-bit Unix timestamp in milliseconds at the front, followed by random bits. You get k-sortable IDs: recent rows cluster in indexes like ULID, while remaining opaque to clients.

PostgreSQL 18+, many ORMs, and Java libraries now ship v7 generators. If you are designing a new multi-tenant SaaS in 2026, v7 is the pragmatic default unless you have a compelling reason for pure randomness.

-- Example: time-ordered inserts cluster better with v7 than v4
-- Application generates v7; DB stores native uuid type
INSERT INTO events (id, payload) VALUES ($1, $2);

Observability tip: v7 exposes millisecond timestamps in the leading bits. That helps support engineers correlate IDs to incidents without a database lookup, but also leaks coarse creation time to clients. If that is undesirable, keep v7 internal and expose opaque v4 externally (dual-column pattern).

Side-by-side comparison

	v1	v4	v7
Sortable by time	Roughly	No	Yes (ms precision)
Index locality	Good	Poor	Good
Predictable	Yes	No	Partially (time visible)
Privacy	Weak	Strong	Moderate
Library support	Universal	Universal	Growing fast

Migrating between versions

Never rewrite existing primary keys in place without a migration plan. Common pattern: add a new v7 column, dual-write, backfill, switch readers, drop old column. For APIs, accept both formats during transition and validate version bits on ingest.

Feature flags help: generate v7 for new tenants only while legacy tenants keep v4 PKs. Document the version mix in runbooks so on-call engineers do not assume time-ordering globally. Add metrics on version nibble distribution in ingestion logs to catch misconfigured generators early.

Load testing note: switching from v4 to v7 often reduces page splits in B-tree indexes on PostgreSQL and MySQL. Measure p95 insert latency and table bloat before/after on a staging clone - the win varies with fill factor and concurrent secondary indexes.

FAQ

Can I use v4 and v7 in the same database?: Yes, but mixed versions in one column complicate time-based queries. Prefer one version per table.
Does v7 replace ULID?: They solve similar problems. ULID is 128 bits with different encoding; v7 stays in canonical UUID string form.
How do I read the version from a string?: Look at the first hex digit of the third group. 4 means v4, 7 means v7, 1 means v1.
What about UUID v3 and v5?: They are name-based (hash of namespace + name). Useful for deterministic IDs, not general PKs.
Does AWS or Azure prefer a version?: Cloud APIs accept standard UUID strings; many now emit v4 or v7 depending on service. Always validate on ingest.
Will ORMs auto-pick v7?: Increasingly yes via configuration. Explicitly set version in greenfield services to avoid surprises across environments.