UUID Versions Explained: v1, v4, v7 and Database Performance

A Universally Unique Identifier (UUID) is a 128-bit label used in software development to identify information without a central authority. The most common format is 36 characters separated by hyphens: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. While the concept sounds simple, the way a UUID is generated has deep implications for database performance, security, and system design. Understanding the differences between UUID versions is not academic — it directly affects how fast your database queries run and how well your distributed system scales.

UUID version 1 generates identifiers using a combination of a timestamp and the MAC address of the generating machine. Because the timestamp is monotonic, v1 UUIDs are time-sortable — a useful property when you need to iterate records in insertion order. However, v1 UUIDs expose sensitive system metadata: the MAC address can reveal which machine generated the ID, and the timestamp leaks information about when the record was created. In security-sensitive or privacy-conscious environments, this is a significant drawback. Additionally, v1 requires a centralized clock source to avoid collisions in distributed setups, making it harder to scale horizontally.

UUID version 4 solves these problems by relying entirely on cryptographically strong random number generation. Of the 128 bits, 6 are fixed for version and variant fields, leaving 122 bits of randomness. This yields approximately 5.3 × 10^36 possible values — making accidental collisions so statistically improbable that they can be safely ignored for any practical application. The absence of timestamps or machine-specific data means v4 UUIDs carry no metadata and require no coordination between nodes, making them the standard choice for most modern distributed systems.

The tradeoff with v4 is performance. Because each generated UUID is effectively random, inserting them into a B-tree index (the default for most database primary keys) causes maximum page fragmentation. B-trees work by keeping data sorted; when you insert a random value, the database must frequently split pages to make room, leading to poor disk locality, increased write amplification, and degraded read performance over time. For high-write workloads, this can cause index bloat and slow down queries significantly. This is the classic UUID-as-primary-key performance pitfall that many engineering teams encounter in production.

UUID version 7 was introduced to address the performance problems of v4 while retaining its privacy benefits. v7 encodes a Unix timestamp in the most significant bits, followed by random data. Because the timestamp changes monotonically, v7 UUIDs are time-sortable and exhibit B-tree friendliness similar to v1, without exposing MAC addresses or requiring synchronized clocks. Most databases can now efficiently append v7 values to the right side of the B-tree index, minimizing page splits and preserving disk locality. This makes v7 a strong candidate for primary keys in new projects that want the uniqueness guarantees of UUIDs with the insert performance of sequential integers.

Choosing the right UUID version ultimately depends on your use case. For session tokens, correlation IDs, and one-off identifiers where ordering does not matter, v4 remains the safest and most widely supported option. For database primary keys in systems with high write throughput, v7 (or even ULID, a similar time-sortable alternative) will yield better performance. If you need strict time ordering across nodes without external clock synchronization, v7 or v1 are both viable, though v7 is preferred for its entropy and lack of hardware dependency. When selecting a version, always evaluate the full lifecycle of the identifier — from generation to storage, indexing, and retrieval — to avoid performance surprises in production.

Bulk UUID generation is essential for seeding test databases, populating staging environments, and generating fixtures for load testing. Generating 1000 v4 UUIDs client-side takes only milliseconds, and modern browsers expose cryptographically strong randomness via crypto.getRandomValues(), ensuring that even bulk-generated batches meet the same entropy standards as single IDs. The key consideration when generating UUIDs in bulk is output format: some systems expect hyphen-separated values for readability, while others require hyphen-free strings for compact storage or processing. Our tool handles both formats and lets you switch between uppercase and lowercase representations to match your system's conventions.