Skip to main content
Back to Blog

UUIDs Explained: v1, v4, v7 and When to Use Them

When to use v4 for randomness, v7 for time-ordered IDs, and how different UUID versions affect databases and distributed systems.

Kashyap Thakar
5 min
DatabaseUUIDArchitecture
UUIDs Explained: v1, v4, v7 and When to Use Them

Universally Unique Identifiers (UUIDs) are 128-bit numbers used to identify information in computer systems. They are designed to be unique across space and time, without central coordination. But did you know there are multiple versions?

The Most Common: UUID v4

UUID v4 is completely random. It uses random numbers for almost all of its bits.

  • Pros: Extremely low collision probability, easy to generate.
  • Cons: Not sortable, bad for database indexing (fragmentation).

The New Standard: UUID v7

UUID v7 is a time-ordered value. It combines a timestamp with random data.

  • Pros: Sortable by creation time, excellent for database primary keys (B-tree friendly).
  • Cons: Reveals creation time (might be a privacy concern).

Legacy: UUID v1

UUID v1 uses the current time and the MAC address of the computer generating it.

  • Pros: Guaranteed uniqueness per machine.
  • Cons: Privacy risk (leaks MAC address), relies on system clock.

Database Performance Impact

The choice of UUID version can significantly impact database performance, especially with large datasets:

  • UUID v4 (Random): Causes index fragmentation because new records are inserted at random positions in the B-tree index. This leads to slower queries and increased storage overhead.
  • UUID v7 (Time-ordered): New records are inserted at the end of the index, maintaining better index locality. This results in faster inserts and more efficient index usage.
  • UUID v1 (MAC-based): Similar to v4 in terms of randomness, but with additional privacy concerns.

For high-traffic applications with millions of records, UUID v7 can provide measurable performance improvements over v4, especially for range queries and time-based filtering.

Use Case Recommendations

Use UUID v7 When:

  • You need sortable identifiers (e.g., for pagination or chronological ordering)
  • Database performance is critical (large tables, high insert rates)
  • You want to extract creation time from the ID itself
  • You're building distributed systems where time-ordering matters

Use UUID v4 When:

  • You need completely random identifiers (security tokens, session IDs)
  • You don't need time-based sorting
  • Privacy is a concern (you don't want to reveal creation time)
  • You're working with smaller datasets where performance isn't critical

Avoid UUID v1 When:

  • Privacy is important (MAC address leakage)
  • You need deterministic generation across different machines
  • You're building modern applications (v7 is the better time-ordered option)

UUID Format Breakdown

All UUIDs follow the same format: 32 hexadecimal digits displayed in 5 groups separated by hyphens:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
Where:
M = version (1, 4, 7, etc.)
N = variant (usually 8, 9, A, or B)

The version number is embedded in the UUID itself, making it easy to identify which version was used to generate a particular UUID.

Which Should You Choose?

For most modern web applications, UUID v7 is becoming the preferred choice for database keys due to its performance benefits. If you just need a random token and don't care about sorting, UUID v4 remains the standard.

The decision often comes down to your specific requirements:

  • Performance-critical databases: Choose v7 for better index performance
  • Security tokens: Choose v4 for maximum randomness
  • Time-based queries: Choose v7 to enable efficient time-range filtering
  • Privacy-sensitive applications: Choose v4 to avoid revealing creation time

Need to generate one quickly? Use our UUID Generator to create v1, v4, and v7 UUIDs instantly. You can generate single UUIDs or batch generate multiple IDs for testing and development.

Part of the ThenCatch blog. Learn more about us or browse more guides.