What is UUID v7?

UUID v7 is the modern UUID standard introduced in RFC 9562 (2024). It encodes a 48-bit Unix millisecond timestamp in the most significant bits, followed by a version nibble and 74 bits of randomness. This makes v7 UUIDs naturally sortable by creation time — just compare them lexicographically.

A v7 UUID looks like: 018e4a61-3b00-7c4a-ab12-f3e6c1234567

The first 12 hex characters encode the Unix timestamp in milliseconds. Because new UUIDs always have a larger timestamp than older ones, they insert at the end of a B-tree index — just like auto-increment integers — eliminating index fragmentation.

Why UUID v7 is the Best Choice for Database Primary Keys

✓ Strengths

  • Lexicographically sortable by creation time
  • Excellent B-tree index locality — no fragmentation
  • No privacy leak — no MAC address
  • Monotonically increasing within the same millisecond
  • Drop-in replacement for v4 in new projects
  • Standardized in RFC 9562 (2024)

✗ Limitations

  • Timestamp is visible — not suitable if creation time must be secret
  • Not yet natively built into all languages (libraries needed)
  • ~74 bits of randomness vs 122 bits in v4 (both are far beyond collision-safe)

UUID v7 Code Examples

JavaScript (Node.js)
// npm install uuid  (v9.0+)
import { v7 as uuidv7 } from 'uuid';

const id = uuidv7();
console.log(id);
// → "018e4a61-3b00-7c4a-ab12-f3e6c1234567"

// The first 12 hex chars encode Unix ms timestamp
// → lexicographic sort = chronological sort
Python
# pip install uuid7
from uuid7 import uuid7

id = str(uuid7())
print(id)
# → "018e4a61-3b00-7c4a-ab12-f3e6c1234567"

# Python 3.12+ has experimental uuid v7 support:
# import uuid
# id = str(uuid.uuid7())  # if available
Go
// go get github.com/google/uuid  (v1.6+)
package main

import (
    "fmt"
    "github.com/google/uuid"
)

func main() {
    id, err := uuid.NewV7()
    if err != nil {
        panic(err)
    }
    fmt.Println(id.String())
    // → "018e4a61-3b00-7c4a-ab12-f3e6c1234567"
}
Java
// com.fasterxml.uuid:java-uuid-generator:5.0+
import com.fasterxml.uuid.Generators;
import java.util.UUID;

UUID id = Generators.timeBasedEpochGenerator().generate(); // v7
System.out.println(id.toString());
// → "018e4a61-3b00-7c4a-ab12-f3e6c1234567"
PHP
<?php
// composer require ramsey/uuid (4.7+)
use Ramsey\Uuid\Uuid;

$id = Uuid::uuid7()->toString();
echo $id;
// → "018e4a61-3b00-7c4a-ab12-f3e6c1234567"

// Laravel (10.x+)
// $id = (string) Str::orderedUuid(); // time-ordered

Frequently Asked Questions

Why is UUID v7 better than v4 for database primary keys?

UUID v4 inserts at random positions in a B-tree index, causing costly page splits and index fragmentation over time. UUID v7 always inserts at the end (new timestamps are always larger), keeping the index compact and sequential — the same behavior as an auto-increment integer. For high-insert-rate tables this can be a significant performance difference.

Is UUID v7 standardized?

Yes. UUID v7 was standardized in RFC 9562, published by the IETF in May 2024. It supersedes RFC 4122 and is the current authoritative standard for UUIDs.

Can I sort UUID v7s as strings?

Yes — standard lexicographic string comparison works correctly for UUID v7. Because the timestamp occupies the most significant bits, v7_a < v7_b as a string comparison means v7_a was generated before v7_b. This works in any language without parsing the UUID.

What about UUID v6?

UUID v6 is also in RFC 9562 — it reorders the v1 timestamp to be lexicographically sortable. It's a transitional version for systems that need to upgrade from v1 without switching to the Unix epoch. For new projects, prefer v7: it's simpler, uses the Unix epoch (familiar to developers), and has better library support.

Recently Generated

Your last 10 generations are saved locally in your browser. Nothing is sent to our servers.