Disclosure: Some tools link to SaaS products we may earn a commission from — at no cost to you. All tools are free and run entirely in your browser. See full disclosure →
IDs
Output

UUID v7 vs UUID v4

UUID v7 is the newer variant, designed to fix a key weakness of v4: randomness makes IDs unsortable. In databases, sortable IDs are worth millions in performance gains because the database can cluster writes and reads.

The Problem with v4

UUID v4 is purely random. Every new ID lands in a random location in the B-tree index. The database has to split pages, rebalance branches, and handle write amplification. For high-volume inserts, this is expensive.

The UUID v7 Solution

UUID v7 encodes a timestamp in the first 48 bits. All UUIDs generated within the same millisecond have the same prefix, so they cluster together naturally. Inserts append to the end of the index (no fragmentation). Databases love this pattern.

Real-World Impact

  • Write latency: v4 causes random page splits; v7 appends sequentially.
  • Index fragmentation: v4 indexes become fragmented over time; v7 stays compact.
  • Range queries: "Get all IDs created in the last hour" is fast with v7 (sequential scan); slow with v4 (random access).
  • Replication: Distributed systems with v7 IDs have natural sorting across replicas.

When to Use UUID v7

  • High-volume inserts: Millions+ per day. v7 reduces database load.
  • Distributed systems: Multiple services generating IDs independently. v7 sorts naturally.
  • Time-series databases: Any system where "time order = importance." v7 encodes both.
  • Microservices: When you want request tracking that also sorts by time.
  • Event sourcing: Append-only logs benefit from sortable IDs.

When to Use UUID v4

  • You need cryptographic randomness (though neither v4 nor v7 are cryptographic).
  • Your system doesn't require sorting by time.
  • You're using databases that don't support v7 (older systems).
  • Legacy code depends on v4 specifically.

UUID v7 Structure

A UUID v7 looks like: 0181b4a6-8d3e-7ab2-8da2-77c0c3f4c5d6

Field Bits Content
0181b4a6 32 Unix timestamp (milliseconds) — high bits
8d3e 16 Unix timestamp (milliseconds) — mid bits
7ab2 16 Version (0111) + random high bits
8da2 16 Variant (10) + random bits
77c0c3f4c5d6 48 Random low bits

Database Support

  • PostgreSQL 13+: Use uuid_generate_v7() extension
  • MySQL 8.0.23+: Use UUID_TO_BIN(UUID()) with manual v7 generation
  • MongoDB 4.4+: BSON UUID type supports v7
  • SQLite: No built-in UUID; use app layer
  • Firestore / Datastore: Supports any UUID format

ORM Support

  • TypeORM: @Column('uuid') with generated: 'uuid_v7'
  • Prisma: @default(uuid(version: 7))
  • Sequelize: Use DataTypes.UUIDV7
  • Mongoose: Native UUID v7 support in recent versions

Performance Comparison

Metric UUID v4 UUID v7
Index writes/sec ~100K (scattered) ~500K (sequential)
Index fragmentation 50-70% after 1M inserts 5-10% after 1M inserts
Range query speed Slow (random IO) Fast (sequential scan)
Entropy (bits) 122 80
Collision probability Negligible Negligible

Numbers based on PostgreSQL benchmarks with 1M+ inserts on commodity hardware.

FAQ

Frequently Asked Questions

Why use UUID v7 instead of v4?

UUID v7 encodes the creation timestamp, making IDs sortable by time. This is valuable in databases where you want natural insertion-order clustering without relying on auto-increment. Modern databases (MongoDB, Postgres, etc.) perform better with sortable IDs because they reduce write-amplification in B-tree indexes. v4 is purely random, so IDs scatter randomly across the index, causing more page splits.

Is UUID v7 suitable for primary keys?

Yes. UUID v7 is better than v4 for primary keys in most databases because of the sortability property. Each new ID naturally appends to the end of the index, improving write performance. Use v7 for high-volume distributed inserts. Use v4 if you need pure randomness for security reasons (though neither should be used as cryptographic secrets).

How does the timestamp work in UUID v7?

UUID v7 encodes the first 48 bits as a Unix timestamp in milliseconds. The remaining 80 bits are random. This means: (1) IDs generated in the same millisecond have the same prefix, improving index locality, and (2) you can extract the creation time from a UUID without a separate timestamp field. The trade-off is slightly less entropy (80 bits vs 122 bits in v4), but still collision-proof in practice.

Can I sort UUID v7 in the database?

Yes. UUIDs v7 sort lexicographically by timestamp. In databases that support binary UUID storage (BINARY(16)), this is extremely fast. String comparison works too but is slower. Many ORMs (TypeORM, Prisma) now have v7 UUID support built-in with auto-sorting.

What is the timestamp resolution?

UUID v7 uses millisecond precision. Multiple UUIDs generated in the same millisecond will have the same timestamp but differ in the random portion. This is sufficient for most use cases. Nanosecond precision would require different ID formats (e.g., ULID uses microseconds).

Is UUID v7 compatible with older systems?

RFC 4122 compliance: yes. Hardware/software that doesn't understand v7 will treat it as opaque bytes and still work. However, sorting might be broken if the system was optimized for v1 or v4. Always ensure database and ORM support v7 before using it. Most modern systems (Postgres 13+, MongoDB 4.4+, Node.js 15.6+) support it natively.

ID & Secret Generators
UUID v4 Generator Nano ID Generator Password Generator API Key Generator
💡
Need AI tools for your development workflow?

Explore our reviews of the best AI coding assistants, documentation generators, and developer productivity tools — ranked by real-world usefulness.

Browse AI Tools for Developers →
The DevTools Team
Infinfy Engineering
We build free developer utilities that we actually use ourselves. No accounts, no tracking, no backend — just fast, accurate, in-browser tools. Part of Infinfy Solutions.