Skip to content
Blog

UUID v7 Generator: Why Time-Ordered IDs Are the Best Choice for Databases in 2026

UUID v7 combines time-ordered inserts with privacy-safe randomness - no MAC address leakage, no index fragmentation. Generate UUID v7 online, free, in your browser.

Share:Twitter/XLinkedIn

If you had to pick one format for every database ID you'd ever create, what would it be? UUIDs are the default in most modern stacks - but not all UUIDs are equally suited for the job. UUID v7 is the version you should be using in 2026, and if your tools don't support it yet, it's time to switch.

The Problem with Random UUIDs in Databases

Most databases default to UUID v4 - the fully random one. crypto.randomUUID() in Node.js, uuid.uuid4() in Python, gen_random_uuid() in PostgreSQL - all random, all the time.

Random UUIDs work. Until they don't.

When you insert a row with a random UUID as the primary key into a B-tree index (the default in PostgreSQL, MySQL, SQLite), the database has to find a place for that new entry somewhere in the middle of the index - not at the end where new inserts normally go. Over time, as millions of rows accumulate, this causes index fragmentation.

Index fragmentation means:

  • Your index is larger than it needs to be (random placement leaves gaps)
  • Reads are slower because the database hops around the index tree
  • Write amplification - every insert potentially triggers index restructuring

This isn't a theoretical problem. A PostgreSQL table with 100 million rows and a random UUID primary key can have an index that's 2–3× the size it would be with a sequential identifier. At scale, that difference costs you in memory, storage, and query latency.

Twitter's snowflake IDs, PostgreSQL's BIGSERIAL, and MySQL's auto-increment all solved this differently - but they all share one property: new IDs always sort after old ones. Time-ordered IDs keep indexes compact and sequential.

UUID v7 brings that property to the UUID world, without the downsides of the older time-based UUIDs.

What Is UUID v7?

UUID v7 is defined by a draft RFC (not yet final, but widely implemented) that encodes a Unix timestamp as the first component of the UUID, with the remaining bits filled with random data.

The structure:

TTTTTTTT-TTTT-7XXX-YXXX-XXXXXXXXXXXX
└─ Unix timestamp (ms) ─┘└ version ┘└ variant
  • Bits 0–47: 48-bit Unix timestamp in milliseconds
  • Bits 48–59: 12 bits of sub-millisecond timestamp data (nanoseconds within the second)
  • Bits 60–63: Version (7) and variant (8, 9, A, B) markers
  • Bits 64–127: 62 bits of cryptographically random data

The result: a UUID that sorts by generation time, contains no information about the generating machine, and works across distributed systems without coordination.

Why not UUID v1?

UUID v1 is time-ordered - but it encodes the MAC address of the generating machine in the node field. That means:

  • Anyone who sees the UUID knows what machine created it
  • You're leaking internal infrastructure information to the outside world
  • In cloud environments where containers and VMs get new MACs constantly, v1 loses its auditability advantage

UUID v7 gives you the time-ordering without the privacy cost.

What Databases Support UUID v7?

Native support:

  • PostgreSQL 17+ - gen_random_uuid(v7) function
  • CockroachDB - gen_random_uuid(v7) (fully supported)
  • MongoDB - UUID v7 as a native type
  • SQLite - via extension

Via libraries:

// JavaScript / TypeScript - uuid library v11+
import { v7 } from 'uuid';
const id = v7();
console.log(id); // "0191a1e0-9e3b-7f3a-a567-0e02e2d5f6b1"

// Python - uuid module (Python 3.12+)
import uuid
id = uuid.uuid7()

// Go - github.com/google/uuid v5+
import "github.com/google/uuid"
id := uuid.Must(uuid.NewV7())

JavaScript doesn't have a native crypto.uuidV7() yet - the Web Crypto API hasn't added it. Until it does, your best bet is a well-maintained library like the uuid npm package.

How to Generate a UUID v7 Online

You don't need to install anything. Toolblip's UUID Generator supports UUID v7 generation entirely in your browser - no data sent to any server.

Generate UUID v7 online →

Just open the tool, select v7 from the dropdown, and copy. Each UUID is generated using the Web Crypto API's crypto.getRandomValues(), so the random bits are properly seeded from your browser's entropy source.

You can generate one UUID at a time or batch-generate thousands for seeding scripts, test data, or migration tooling.

When to Use UUID v7 (And When Not To)

Use UUID v7 when:

  • You're designing a new system with a UUID primary key
  • You care about database write performance at scale
  • You want time-ordering for audit logs or event streams
  • You're working in a distributed environment without a central ID coordinator

Stick with UUID v4 when:

  • IDs are generated by different systems and you can't guarantee timestamp consistency (clock skew issues)
  • You're using a database that has efficient sequential ID generation built in (and you don't need UUIDs specifically)
  • You need deterministic IDs from the same input (use v5 for that)

Use UUID v1 for legacy systems where the audit trail of machine identity genuinely matters and you understand the privacy trade-off.

UUID v4 vs UUID v7: What's the Real Difference?

Here's a side-by-side for the two versions most developers choose between:

Property UUID v4 UUID v7
Sort order Random - no time correlation Time-ordered - later = larger
Privacy ✅ No info leaked ✅ No info leaked
Index friendliness ❌ Causes fragmentation ✅ Sequential inserts
Distributed generation ✅ No coordination needed ✅ No coordination needed
Browser-native support crypto.randomUUID() ❌ Requires a library
Database native support PostgreSQL, MySQL, SQLite PostgreSQL 17+, CockroachDB, MongoDB
Collision probability Effectively zero Effectively zero

The only real advantage UUID v4 has in 2026 is ecosystem maturity. Every language has a v4 generator. Every database has a native v4 function. UUID v7 is catching up fast - PostgreSQL 17's native support alone covers a huge portion of new database deployments.

If you're starting a new project today, there's no reason to default to v4.

The Broader Shift Away from Auto-Increment IDs

REST APIs, microservices, and multi-region deployments have pushed developers away from auto-increment integer IDs for years. Sequential integers leaked insertion order, couldn't be generated across regions without a central coordinator, and were guessable.

UUIDs solved those problems - but the cost was random writes and bloated indexes. UUID v7 is the answer to that tradeoff: distributed-generation-safe IDs that still preserve insert locality.

This matters more as more systems move to append-only event logs, CQRS patterns, and distributed databases where "when did this happen?" is a queryable property of the ID itself.

Related Tools

  • UUID Generator - Generate UUID v4 and v7 instantly in your browser
  • JSON Formatter - Validate and pretty-print JSON with syntax highlighting
  • Hash Generator - Generate MD5, SHA-1, SHA-256, and SHA-512 hashes client-side

Further Reading


No data leaves your browser. All UUID generation on Toolblip uses the Web Crypto API - your entropy never touches a server.

More in Developer Tools
Why Browser-Based Tools Are the Future
4 min read
How to Optimize Images Without Uploading
4 min read
Top 5 Developer Tools You Should Bookmark
5 min read