Why is UUID v7 better than v4 for database keys?

Its leading timestamp makes inserts append to the end of the index rather than scattering randomly, which avoids page splits and keeps the hot part of the index in memory. On large tables the difference in insert throughput is substantial.

Is v7 as unique as v4?

For practical purposes yes. It has 74 random bits within each millisecond, which is far more than enough to avoid collisions at any realistic generation rate.

Does v7 leak information?

It reveals creation time to the millisecond, and a series of IDs reveals creation rate. Use v4 for public identifiers where that matters.

Can I mix v4 and v7 in the same column?

Yes. Both are valid 128-bit UUIDs distinguished by their version nibble, so existing v4 rows remain valid while new rows use v7.

Security🌐 YAS server-sideAPI availablebeginner

UUID v7 Generator

Generates UUID v7 — time-ordered, sortable identifiers.

Processed by YAS · not stored

Ready to runInstant execution

All tools →

Loading tool…

What does this tool do?

Generates UUID v7 — time-ordered, sortable identifiers.

Why would I use it?

You want IDs that sort chronologically for database index performance.
You need unique IDs plus rough creation order.
You are using UUIDv7-supporting databases (Postgres 18+, MySQL 9+).

Real-life example

Input

count 1

Output

0197b2a0-...-7...

The leading bits encode a timestamp.

Input → Process → Output → Next

Input: Choose count.
Process: YAS builds time-ordered UUIDs with random tails.
Output: UUID v7 strings.
Next action: Use them as primary keys that index efficiently.

Common mistakes

Using v7 when you need unguessable opaque IDs (v4 is better).
Extracting timestamps from v7 in production code (fragile).
Expecting strict ordering across machines with skewed clocks.

What the result means

The timestamp prefix makes v7 roughly sortable by creation time.

Privacy & security

Your input is sent to YAS infrastructure because the tool requires server-side processing or public network queries. Input is not stored.

API

Endpoint

POST https://yas.sh/api/v1/tools/uuid-v7

Request Header

Content-Type: application/json

cURL

curl -X POST "https://yas.sh/api/v1/tools/uuid-v7" \
  -H "Content-Type: application/json" \
  -d '{"count":1}'

JavaScript

const res = await fetch("https://yas.sh/api/v1/tools/uuid-v7", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
  "count": 1
}),
});
const data = await res.json();

Python

import requests

r = requests.post("https://yas.sh/api/v1/tools/uuid-v7", json={"count":1})
data = r.json()

Field	Type	Required	Description
count	integer	No (default 1)	How many (1–50)

Success response

{ "version": 7, "count": 1, "result": "018f...-...-7...-..." }

Generate time-ordered (sortable) UUID v7.

Error responses

400 VALIDATION_ERROR — invalid input or unsupported option.
413 PAYLOAD_TOO_LARGE — input exceeds the 64 KB limit.
429 RATE_LIMIT_EXCEEDED — rate limit exceeded (60 req/min).

Limits

Maximum input: 64 KB per request.
Rate limit: 60 requests/min per IP address.
Authenticated accounts benefit from higher tier quotas.

How UUID v7 Generator works

UUID version 7, standardised in RFC 9562 in 2024, places a 48-bit Unix millisecond timestamp in the most significant bits, followed by the version and variant nibbles and 74 bits of randomness. It keeps the familiar 36-character UUID text form and fits any UUID column, while making the value time-ordered — the property v4 conspicuously lacks.

Ordering matters because of how B-tree indexes behave. Random v4 keys insert at arbitrary positions, dirtying many pages, splitting nodes and destroying cache locality; on a large table this shows up as write amplification and slower inserts. v7 keys append near the rightmost leaf, so the working set stays small and range queries over recent records become sequential scans.

When to use it: real-world scenarios

Primary keys in a high-insert table

The measurable difference against v4 appears once the index no longer fits in memory, which is exactly when it is most painful to change.

Event and audit identifiers

Time-ordered IDs let you page through events by ID without a secondary timestamp index, and the order is stable.

Client-generated IDs in an offline-capable app

Records created offline retain approximate creation order once synchronised, without a server round trip to assign identity.

Migrating from v4 without changing the column type

Both are UUIDs, so new rows can use v7 while existing v4 values remain valid — no schema change required.

Pro tips

Store as 16 bytes (BINARY(16), uuid, RAW(16)) rather than as a 36-character string. The text form more than doubles storage and slows every index comparison.
PostgreSQL 18 and later provide uuidv7() natively; earlier versions and other engines need an extension or application-side generation.
v7 exposes creation time. Where that is sensitive, keep v4 for the public identifier and v7 for the internal key.
Do not mix generators with different clock sources. Ordering guarantees rest on the clocks being roughly synchronised.

Limitations and edge cases

What this tool deliberately does not do, and where it will disagree with other implementations.

The timestamp is recoverable, disclosing creation time and, in aggregate, creation rate.
Ordering is only as good as the clocks; NTP steps and clock skew between hosts can produce locally out-of-order values.
Millisecond granularity means IDs created in the same millisecond are ordered only by their random component.
Older libraries and database versions may not generate or recognise v7 natively.

Frequently asked questions

Why is UUID v7 better than v4 for database keys?: Its leading timestamp makes inserts append to the end of the index rather than scattering randomly, which avoids page splits and keeps the hot part of the index in memory. On large tables the difference in insert throughput is substantial.
Is v7 as unique as v4?: For practical purposes yes. It has 74 random bits within each millisecond, which is far more than enough to avoid collisions at any realistic generation rate.
Does v7 leak information?: It reveals creation time to the millisecond, and a series of IDs reveals creation rate. Use v4 for public identifiers where that matters.
Can I mix v4 and v7 in the same column?: Yes. Both are valid 128-bit UUIDs distinguished by their version nibble, so existing v4 rows remain valid while new rows use v7.

Related tools

UUID Generator