UUIDv4 vs UUIDv7 for Database Primary Keys: A Backend Engineer's Take

If you're choosing a UUID version for your database primary keys, use UUIDv7. UUIDv7 embeds a 48-bit Unix timestamp in the first 48 bits, which means generated IDs sort roughly in creation order. This sequential-friendly ordering prevents the B-tree index fragmentation that plagues UUIDv4 — where completely random IDs cause page splits, write amplification, and index bloat that can slow inserts by 2–3x and balloon index size by 30–50% over time. If you're building a system that writes at any meaningful scale, UUIDv4 silently eats your database performance, and you won't notice until it's too late.

I've watched this exact problem surface in production more than once. A team picks UUIDv4 because "UUIDs mean no collisions, and v4 is the default everywhere." Six months later, their insert throughput craters and someone discovers the primary key index is 40% larger than the actual data. That's when the postmortem starts. Let me save you that postmortem.

The Problem: Why UUIDv4 Hurts Your Database

To understand the issue, you need to understand how B-tree indexes work — and specifically how they handle inserts.

B-tree indexes expect ordered inserts

A B-tree index (used by both InnoDB in MySQL and the default index type in PostgreSQL) stores keys in sorted order within fixed-size pages — typically 16 KB in InnoDB and 8 KB in PostgreSQL. When you insert a new row with a primary key that falls between two existing keys in a full page, the database must perform a page split: it allocates a new page, moves roughly half the rows over, and updates pointers. This is expensive. It writes extra data, fragments the index on disk, and leaves pages half-empty.

With a sequential key — like an auto-increment integer or a time-sorted UUID — new rows always land at the rightmost edge of the index. The database appends to the last page until it fills up, then starts a new one. Clean, efficient, minimal overhead.

UUIDv4 is the opposite. Every insert lands at a random position in the index. Every. Single. Time.

What this looks like in numbers

Here's what I've measured running 1 million inserts into MySQL 8.0 (InnoDB) and PostgreSQL 16 on modest hardware (8 vCPU, 32 GB RAM, NVMe SSD):

These numbers aren't hypothetical. The difference between UUIDv4 and UUIDv7 on B-tree indexes is one of the few things in database engineering where you get a 2x improvement by changing a single decision — no schema changes, no query rewrites, no hardware upgrades. Just pick the right UUID version.

The page split cascade effect

Here's the part that catches teams off guard: page splits aren't a one-time cost. After a split, you have two half-empty pages. Future random inserts might land in either one. Now both are filling unevenly. Within a few hundred thousand rows, your index pages average 60–70% fullness instead of the ideal ~90%+. That means your working set no longer fits in the buffer pool. Queries that used to hit memory now hit disk. Latency spikes. The DBA gets paged at 3 AM.

This is also why simply adding more RAM doesn't fully solve the problem — UUIDv4 indexes are 30–50% larger for the same data, so you need proportionally more buffer pool to keep them in memory. At scale, that translates to real infrastructure spend.

How UUIDv7 Fixes This (and How It Works)

UUIDv7 is defined in RFC 9562 (May 2024). Its structure is beautifully simple:

UUIDv7 layout (128 bits total):

| 48 bits: Unix timestamp (ms) | 4 bits: version (0x7) | 12 bits: random A | 2 bits: variant (10) | 62 bits: random B |

Example: 018f3c5a-7000-7a1b-b4c5-d6e7f8a9b0c1
         ^^^^^^^^^^^^    ^  ^
         timestamp       |  random
                       version=7

The first 48 bits are a Unix timestamp in milliseconds. This is the key insight: because these bits are the most significant bits of the UUID, UUIDv7s sort chronologically when compared as raw bytes. The remaining 80 bits are random (or pseudo-random), which preserves collision resistance for distributed generation.

Why this matters for B-trees

When inserts arrive roughly in time order — even if slightly out of order due to clock skew across application servers — the new keys land near the right edge of the B-tree. The database rarely needs to split interior pages. Index pages fill to their natural capacity (90%+). The buffer pool caches the "hot" rightmost pages, and older pages age out naturally. Everything the database engine is optimized for actually happens.

Millisecond precision gotcha

UUIDv7 uses millisecond precision for the timestamp. This means if your application generates more than ~1,000 UUIDs per millisecond on a single node, you will get collisions in the timestamp portion — and the spec doesn't mandate sub-millisecond sequencing. The spec allows implementations to use additional counter bits in the random portion, but it's not required. If you're generating UUIDs at rates above ~1M/second across your cluster from a single generator instance, you need to be aware of this. At that scale, you probably want ULIDs or a dedicated ID service anyway.

UUIDv7 Gotchas: When v4 Is Still the Better Choice

UUIDv7 isn't a silver bullet. There are real tradeoffs you should understand before adopting it.

Gotcha 1: UUIDv7 leaks creation timestamps

The timestamp in the first 48 bits is a privacy and security consideration. Anyone who sees a UUIDv7 knows exactly when that record was created, down to the millisecond. For most applications this is harmless — your users probably don't care when their comment was assigned an ID. But if you're building something where creation time is sensitive (anonymous reports, whistleblower platforms, rate-limit bypass detection), UUIDv4's random structure is genuinely better. With v4, the ID reveals nothing.

There's a related concern: if you expose UUIDv7s in URLs or API responses, an attacker can scan for IDs created in a specific time window. UUIDv4 makes that kind of enumeration worthless. Whether this matters depends on your threat model, but it's worth flagging in a security review.

Gotcha 2: Native database support is still maturing

As of 2026, here's where things stand:

• PostgreSQL: No built-in uuid_generate_v7() yet. You can use the pg_uuidv7 extension, generate v7 in application code, or use uuid_generate_v7() from the community uuid-ossp fork. The core team has shown interest but hasn't shipped it in core yet.
• MySQL 8.0 / 8.4: No native UUIDv7 function. UUID() still returns UUIDv1 (which has its own timestamp-ordering quirks but with MAC address leakage). You must generate v7 in your application layer.
• MySQL 9.0+ (innovation release): UUID_TO_BIN() and BIN_TO_UUID() exist but don't directly produce v7. Application-side generation remains the safest path.
• MariaDB: No native UUIDv7 as of 11.x.
• SQLite: No built-in UUID type at all — you're storing blobs or text regardless.

The practical takeaway: generate UUIDv7 in your application code. Don't wait for the database to support it. This is actually the recommended pattern even for UUIDv4 — avoid round-tripping to the DB just to get an ID before inserting.

Gotcha 3: Clock skew across distributed nodes

If you run multiple application servers with unsynchronized clocks, UUIDv7s generated on different nodes will have timestamps that diverge. UUIDv7s from a node with a clock 5 seconds behind will sort before IDs generated 5 seconds earlier on a correctly-synced node. For most workloads this is fine — they're still "roughly" time-ordered and the B-tree will handle them efficiently. But if you need strict global ordering, UUIDv7 alone won't give you that. You need a centralized sequencer (like Twitter Snowflake or a DB sequence) or at least NTP-synced clocks.

When UUIDv4 is genuinely the right choice

Use UUIDv4 when:

• You must not leak creation timestamps (privacy/security requirement)
• Your write volume is low — under 100 writes/second sustained. At that rate, page splits are a rounding error.
• You're building a prototype or internal tool where database performance doesn't matter
• You need maximum portability and every library in every language supports v4 today
• You're storing UUIDs as primary keys in a non-B-tree structure (hash indexes, LSM trees like RocksDB) where random keys don't cause write amplification

Implementation: Generating UUIDv7 in Your Language

Here's how to generate UUIDv7 in the languages I work with most often. Every example generates the UUID entirely in application code — no database round-trip needed.

Java

// Using java-uuid-generator (com.github.f4b6a3:uuid-creator:5.3.+)
import com.github.f4b6a3.uuid.UuidCreator;

UUID id = UuidCreator.getTimeOrderedEpoch();
// 018f3c5a-7000-7a1b-b4c5-d6e7f8a9b0c1

This is my go-to library. It's fast (3–5 million UUIDs/second on a modern CPU), handles clock regression correctly, and follows the RFC precisely.

JavaScript / TypeScript

// Use the uuid package (npm install uuid)
import { v7 as uuidv7 } from 'uuid';

const id = uuidv7();
// '018f3c5a-7000-7a1b-b4c5-d6e7f8a9b0c1'

// Edge runtime / zero-dependency alternative:
const id = crypto.randomUUID(); // UUIDv4 only, no v7 yet
// For v7 without dependencies, you'll need a custom implementation
// or use the 'uuid' package which works in Node, Deno, and browsers.

Note: crypto.randomUUID() in the Web Crypto API and Node.js only generates UUIDv4. Chrome has shown interest in a v7 variant but it hasn't shipped yet (as of Chrome 130). Use the uuid npm package — it's 4 KB gzipped and has zero dependencies.

Python

# Python 3.14+ (planned) or use uuid7 package: pip install uuid7
import uuid7

id = uuid7.uuid7()
# UUID('018f3c5a-7000-7a1b-b4c5-d6e7f8a9b0c1')

# Or with the uuid6 package (pip install uuid6):
from uuid6 import uuid7
id = uuid7()

Python's standard library uuid module only supports v1, v3, v4, and v5. There's a PEP 762 proposal to add UUIDv6/v7/v8 to the stdlib, but for now you need a third-party package.

Go

// Using github.com/google/uuid (v1.6.0+)
import "github.com/google/uuid"

id, err := uuid.NewV7()
if err != nil {
    // handle clock regression
}
// id.String() = "018f3c5a-7000-7a1b-b4c5-d6e7f8a9b0c1"

The Google UUID package added v7 support in v1.6.0. It's well-tested and widely used. If you need a lighter alternative, github.com/gofrs/uuid also supports v7.

Rust

// Using the uuid crate with v7 feature: uuid = { version = "1", features = ["v7"] }
use uuid::Uuid;

let id = Uuid::now_v7();
// 018f3c5a-7000-7a1b-b4c5-d6e7f8a9b0c1

The uuid crate supports v7 natively as of version 1.6. It's fast and follows the RFC.

UUIDv7 vs ULID vs Snowflake: Quick Comparison

A question that always comes up: if time-ordering matters, why not just use ULIDs or Snowflake IDs?

• ULID (26 characters, Crockford base32): Also time-ordered and 128-bit. ULID is essentially UUIDv7 with a different string encoding and 1ms precision with monotonic sequencing built in. The main advantage over UUIDv7 is compactness (26 chars vs 36). The main disadvantage: UUIDs are a universal standard — every database, ORM, and logging framework understands them natively. ULIDs require conversion to/from UUID format to store in UUID columns.
• Snowflake (Twitter, 64-bit integer): Time-ordered with worker/machine ID and sequence number. Faster than UUIDv7 for single-machine workloads because it's only 64 bits. The downside: you need a coordination service to assign worker IDs, and 64 bits limits you functionally. Snowflakes don't fit in UUID columns.
• UUIDv7 wins on ecosystem compatibility. It's a standard UUID that every tool already understands. You get time-ordering without changing your schema, your serialization format, or your tooling.

Migration Path: Moving from UUIDv4 to UUIDv7

If you're already running UUIDv4 in production, you can migrate incrementally:

1. Start generating v7 for new records. UUIDv7 and UUIDv4 can coexist in the same UUID column. Old v4 rows stay where they are. New v7 rows insert near the right edge. Over time, as old data ages out of the active working set, your insert and query performance improves organically.
2. Don't bother backfilling old v4 IDs. Re-keying production data is risky and the performance gain wouldn't justify the operational complexity. The B-tree pages holding old v4 data will eventually stabilize if you stop inserting random keys into them.
3. Update your ID generation library everywhere. This is the real work — making sure every service, background job, and script uses v7 instead of v4. Add a linter rule or a custom UUID factory that enforces v7 for new code.
4. Monitor index bloat. After switching, watch pg_stat_user_indexes (PostgreSQL) or information_schema.innodb_metrics (MySQL) to confirm index sizes are growing linearly with row count rather than super-linearly.

Bottom Line

UUIDv4 was the right default for a decade because there was no better option. UUIDv7 is the better option now. If you're starting a new project today, use UUIDv7 for your primary keys. Your future self — and your database — will thank you.

The one-liner I give every team I work with: "UUIDv7 gives you everything UUIDv4 promised — distributed uniqueness with no central coordinator — minus the part where it silently destroys your database performance."

Want to experiment with UUIDs? Try ToolStand's free UUID Generator (currently v4, v7 support coming soon — we're building it as I write this).