Random vs Ordered UUID: Which Should You Use?
Random UUID (v4) Overview
A random uuid — typically UUID v4 — is generated from 122 bits of randomness plus six fixed bits. No two machines need to coordinate, no central authority is involved, and any client can mint one on its own. That makes UUID v4 the easiest identifier to create: you press a button on a random uuid generator and get a globally unique value instantly.
The practical probability of a collision is essentially zero. With 2^122 possible values, you would need to generate billions of UUIDs per second for trillions of years before two matched. For most applications, uniqueness is simply a non-issue, which is why v4 is the default choice for IDs, API keys, and client-generated records.
Generating one is trivial: a random uuid generator fills 122 bits from a cryptographically secure source and formats them into the familiar 8-4-4-4-12 shape. You can mint thousands per second on a laptop, with no coordination between machines.
The downside of a purely random identifier is that it carries no ordering information. Two UUIDs created milliseconds apart look completely unrelated, and a database cannot tell which was created first without storing a separate timestamp column alongside them.
Ordered UUID & Time-Based (v1/v7)
An ordered UUID embeds time into the value itself, so identifiers sort by creation order. UUID v1 uses a timestamp plus the generating machine's MAC address, while UUID v7 (RFC 9562, 2024) starts with a 48-bit Unix millisecond timestamp followed by random bits.
Because the timestamp sits at the front, a v7 UUID is naturally sortable and monotonic within a single generator. Insert the values into a B-tree index and new keys land near the end of the index rather than at random positions. That ordering is exactly what databases want, and it is the main reason the standard was created in the first place.
The trade-off is that an ordered UUID reveals when a record was created, because the creation time is embedded in the value. v1 also leaks the generating machine's MAC address, a privacy concern that is one reason v1 has largely fallen out of favor. v7 keeps millisecond precision without the MAC address, so it is the safer time-based option for modern applications.
Database Indexing Impact
Primary keys are stored in an index — usually a B-tree — and the order of insertion matters enormously for performance. With a random uuid (v4), each new row points to a random spot in the index, so inserts trigger scattered page splits and force the database to shuffle existing pages around. This is called index fragmentation, and it degrades both write throughput and cache efficiency on busy tables.
With a time-ordered key (v1/v7), new rows append near the end of the index. The database can write sequentially, keep the hottest pages in memory, and avoid the constant page-split churn that random keys cause. On a high-volume, write-heavy workload the difference can be dramatic — often the deciding factor in choosing v7.
It is worth noting that the fragmentation effect applies when a random UUID is used as a primary key, not when a UUID is just an ordinary column. If the identifier is never used to order or index the rows, the performance cost is small and v4 remains perfectly fine.
| | UUID v4 (random) | UUID v7 (ordered) | |---|---|---| | Insert position | Random across the index | Appends near the end | | Page splits | Frequent | Rare | | Cache efficiency | Poor | Good | | Sequential writes | Discouraged | Encouraged | | Reveals creation time | No | Yes (millisecond) | | Collision risk | Astronomically low | Astronomically low |
Practical Recommendation
Reach for a random uuid generator by default. UUID v4 is simple, stateless, and collision-proof, and for the vast majority of projects — moderate write volume, non-indexed identifiers, client-side generation — the theoretical index cost is irrelevant.
Switch to UUID v7 when you have a high-concurrency primary key, a write-heavy database, or a table frequently queried by insertion order. Use v7 when you need B-tree-friendly sequential inserts and the embedded timestamp is acceptable. Use v1 only if you specifically need MAC-based uniqueness and can live with the privacy trade-off, which is rare today.
When in doubt, generate a few of each with our UUID generator and reason about your workload: random for flexibility, ordered for write performance.
Here is a quick decision rule. If you are building a user-facing app where IDs are created on the client, stored in a local first database, or simply need to be unique without revealing timestamps, stay on UUID v4. If you are running an ingestion pipeline, a high-throughput message queue, or a table where recent rows are read far more often than old ones, move to UUID v7. You can always add a separate created_at column and keep v4 — the trade-off is a small amount of extra storage versus better index locality.
FAQ
Q: Are UUIDs random?
UUID v4 UUIDs are generated from random numbers with 122 random bits, so collisions are astronomically unlikely.
Q: Is UUID v4 unique enough?
Yes. With 2^122 possible values, the chance of a collision is negligible for realistic workloads.
Q: What causes UUID index fragmentation?
Inserting random keys into a B-tree index causes random page splits and cache misses; ordered or time-based UUIDs avoid this.