UUID v7 Generator — Time-Ordered UUIDs for Database Primary Keys

What is UUID v7 Generator?

UUIDv7 is the modern replacement for UUIDv4 as a database primary key. It looks like a normal UUID but its first 48 bits encode the current Unix time in milliseconds, followed by 74 bits of cryptographic randomness. The result: globally unique identifiers that also sort by creation time — no more random-IO index thrashing, and no more scanning `created_at` to figure out row order.

How to generate UUIDv7

1. 1Click Generate to create a single UUIDv7 with the current timestamp.
2. 2For batch generation, increase the count (up to 10,000 at once) — each ID is unique and monotonically increasing within the batch.
3. 3Copy any single ID with one click, or copy the whole list as JSON, CSV, or one-per-line.
4. 4The tool also shows the embedded timestamp and remaining random bits — useful for verifying implementation correctness.

Use Cases

Code Examples

import { v7 as uuidv7 } from "uuid";

const id = uuidv7();
// 01924567-89ab-7cde-8f01-234567890abc

# Python 3.13+ (uuid.uuid7)
import uuid
id = uuid.uuid7()

# Earlier Python: pip install uuid7
from uuid7 import uuid7
id = uuid7()

import "github.com/google/uuid"

id, err := uuid.NewV7()
fmt.Println(id.String())

-- Native uuidv7() function
SELECT uuidv7();

-- Column default
CREATE TABLE events (
  id uuid PRIMARY KEY DEFAULT uuidv7(),
  payload jsonb NOT NULL,
  created_at timestamptz DEFAULT now()
);

Key Concepts

UUIDv7 layout

128 bits total: 48 bits unix-time-ms | 4 bits version (0111) | 12 bits sub-ms random | 2 bits variant (10) | 62 bits random. That's 74 bits of randomness — 2⁷⁴ ≈ 1.9×10²² possible IDs per millisecond. Collisions are effectively impossible.

Why not just UUIDv4 + created_at?

Two problems: (1) v4's random primary keys wreck B-tree performance because inserts scatter across pages. (2) Ordering by `created_at` needs a separate index. UUIDv7 solves both — it's naturally ordered *and* unique.

ULID vs UUIDv7

ULIDs predate UUIDv7 and solve the same problem. ULIDs use Crockford Base32 (26 chars), UUIDv7 uses hex (32 chars + dashes). ULIDs are shorter and more URL-friendly; UUIDv7 is an IETF standard (RFC 9562, 2024) with native database support arriving fast.

Monotonicity within a millisecond

Multiple IDs generated in the same millisecond need a tiebreaker to stay ordered. Common approach: use the sub-ms field as a counter that increments (with random start), overflowing into the next millisecond if it exhausts. This tool implements that so batch-generated IDs are strictly monotonically increasing.

Tips & Best Practices

• ▸Store UUIDv7 as `uuid` in Postgres and `BINARY(16)` in MySQL. Never store as string — you'll double the size and lose the sort benefit.
• ▸For public-facing IDs (URLs, API endpoints), keep using something opaque (nanoid, short hash). UUIDv7 leaks creation time — sometimes that's fine, sometimes it's a subtle privacy issue.
• ▸If you index UUIDv7 in Elasticsearch or OpenSearch, keep it as `keyword` and set `doc_values: true`. Range queries on the ID range become time-range queries — very efficient.
• ▸Never generate UUIDv7s across servers with unsynchronized clocks. NTP drift of even 100ms breaks the ordering guarantee. In production, run NTP + monitor drift.