UUID v7 Generator Guide: Sortable IDs for Developers

Understand UUID v7 vs v4, why time-ordered IDs improve database performance, and how to generate bulk UUIDv7 values for seeds and fixtures.

13 min readUpdated

If you have ever watched a PostgreSQL primary key index bloat while UUIDv4 rows arrive in random order, you already know why the industry is moving to UUID v7. UUID v7 embeds a millisecond timestamp in the first 48 bits, making identifiers naturally sortable by creation time while retaining global uniqueness. Developers building distributed systems, event stores, and high-write tables are adopting UUIDv7 as the default — and they need easy ways to generate values for local development, seed scripts, and API testing.

This guide explains UUID v7 vs v4, database performance implications, RFC 9562 format details, and practical bulk generation workflows for engineering teams.

What is UUID v7?

UUID v7 is defined in RFC 9562 (2024) as a time-ordered UUID variant. The first 48 bits encode a Unix timestamp in milliseconds; version bits mark it as v7; the remaining bits carry randomness for uniqueness. The result looks like a standard UUID string — xxxxxxxx-xxxx-7xxx-yxxx-xxxxxxxxxxxx — but sorts chronologically when used as a primary key or index column.

UUID v7 vs UUID v4

UUID v4 is entirely random. Inserted into a B-tree index, v4 primary keys land in random leaf pages, causing page splits, fragmentation, and reduced cache locality on large tables. UUID v7 inserts approximate sequential order, keeping index pages hot and append-friendly — similar to auto-increment integers but without centralized ID coordination across distributed services.

  • UUID v4: maximum randomness, poor index locality, legacy default in many ORMs
  • UUID v7: time-ordered, excellent index behavior, ideal for distributed PKs
  • UUID v1: time-based but exposes MAC address (privacy concerns) — largely deprecated
  • Auto-increment: best index performance but requires single-writer or coordination

Why database engineers prefer UUID v7

On tables with millions of rows — orders, events, audit logs, messages — random UUID primary keys inflate index size and slow writes. Benchmarks commonly show 20-40% write throughput improvements when switching from v4 to v7 on SSD-backed PostgreSQL with default B-tree indexes. Read patterns that scan recent rows by ID also benefit because newest records cluster at the index tail.

Distributed systems without ID coordination

Microservices generating IDs independently cannot safely use auto-increment without a central allocator. UUID v7 lets each service mint IDs locally with negligible collision probability and natural time ordering for debugging — grep logs by ID range approximate creation window.

UUID v7 format breakdown

Example: 01944f3a-b2c1-7d4e-a8f0-1234567890ab. The leading hex digits encode timestamp; the '7' in the third group indicates version; variant bits appear in the fourth group; trailing bits are random. Validators check version and variant fields — generators must set these correctly for interoperability with strict parsers.

When to use UUID v7

  1. Primary keys on high-insert tables (events, notifications, analytics rows)
  2. Public-facing opaque IDs where enumeration attacks matter
  3. Distributed services without shared ID sequence
  4. API resource identifiers needing time-sortable pagination cursors
  5. Replacing UUID v4 in greenfield projects targeting PostgreSQL 17+ native support

UUID v7 reveals creation time at millisecond precision — acceptable for most apps but avoid if ID timestamps must remain secret from clients.

Bulk UUID v7 generation for seeds and tests

Migration dry-runs, factory fixtures, and load tests need thousands of IDs fast. Bulk generators output lists ready for SQL INSERT statements, JSON fixtures, or Postman environment variables. Because v7 IDs sort by generation time, bulk batches are naturally ordered — useful for testing cursor pagination and 'latest first' queries.

Database and ORM compatibility

PostgreSQL uuid type accepts v7 strings natively. MySQL stores them as CHAR(36) or BINARY(16). Prisma, Drizzle, and TypeORM treat them as string UUID fields — no schema change from v4 beyond generation logic. Some databases add native uuid_generate_v7() functions; browser-side generators fill the gap for ad-hoc development.

Testing considerations

Mock time in unit tests if generation is time-dependent. Verify uniqueness constraints under concurrent inserts in integration tests. Test API serializers accept lowercase and uppercase hex. Ensure pagination endpoints handle monotonic ID ordering correctly when migrating from v4 legacy rows mixed with v7 new rows.

Free UUID v7 generator

Our tool generates standards-compliant UUIDv7 values in single or bulk mode with one-click copy. Use it for seed scripts, Postman collections, and local development — no install, no sign-up.

Frequently Asked Questions