What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
UUIDs are 128-bit identifiers designed to make independently generated IDs practically unique, not mathematically impossible to duplicate. For a new distributed system that benefits from sortable database keys, UUIDv7 is a strong candidate; UUIDv4 remains useful when random ordering is preferred and its index locality is acceptable. The right choice depends on how your database orders UUIDs and how your application writes data.
Which UUID version should I use? Start with the workload, database engine, privacy needs, and compatibility requirements—not the version number alone.
Can UUIDs collide?
Yes. “Universally unique” describes a practical engineering goal, not a proof that a collision can never occur. A UUID is 128 bits, but formats reserve some bits for the version and variant, leaving fewer than 128 bits for random data. UUIDv4, for example, has 122 random bits. The IETF’s RFC 9562 explains that true global uniqueness is impossible without shared knowledge; UUIDs instead make collisions sufficiently unlikely for practical uses when generated correctly.
The consequences of a collision depend on the application. A database uniqueness constraint can reject a duplicate primary key, but the application still needs a way to handle that failure. For systems where a collision would be costly, use a suitable generator, enforce uniqueness at the storage boundary, and plan for conflicts rather than assuming they cannot happen.
#1 Best Overall
Which UUID version should I use?
For a new distributed application whose database benefits from time-ordered keys, evaluate UUIDv7 first. It can be generated independently across machines and sorts by time in its leading fields when compared as raw bytes. Choose UUIDv4 when random ordering is desirable, timestamp ordering leakage is unwanted, or the write pattern and database make index locality unimportant.
- UUIDv7: A practical starting point for distributed systems that want time ordering and potentially better index locality in databases that sort UUID bytes accordingly.
- UUIDv4: A random identifier with no embedded creation time. Its inserts are scattered through a byte-sorted B-tree, which can be undesirable for some write-heavy workloads.
- UUIDv6: A time-ordered alternative that rearranges UUIDv1-style timestamps so raw-byte sorting follows time.
- UUIDv1: Consider only when its timestamp and node behavior are intentional; the standard notes privacy concerns associated with its node value, which may expose a MAC address.
- UUIDv3 and UUIDv5: Deterministic name-based identifiers. They are useful when the same namespace and name should produce the same ID, but a mutable business value is usually a poor substitute for an immutable database surrogate key.
Decide by checking whether identifiers must be generated independently, how the database orders them, whether time information may be exposed, the quality of the generator, the cost of collisions, and compatibility with existing schemas and APIs. RFC design properties are not a benchmark for a particular deployment.
Is UUIDv7 better than UUIDv4 for database indexes?
It can be, in a database whose UUID comparison follows byte order and in a workload where inserts are a meaningful part of the cost. UUIDv4 values are random, so new entries can land at many positions in a B-tree rather than clustering near its right edge. UUIDv7 places a Unix timestamp in its leading portion, so nearby generation times produce values that are close in byte order. RFC 9562 says time-ordered UUIDs can improve database-index locality because new values are near one another in the index.
This is an index-locality argument, not a guarantee of faster queries or a universal performance win. UUIDv7 still has random or counter fields, and database behavior depends on its comparison semantics, indexes, write pattern, concurrency, and other workload details. Measure the deployed engine and application before migrating for presumed speed gains.
Rank #3
Why the database engine matters
Do not assume every database sorts UUIDs by comparing the same 16 bytes in the same order. Microsoft’s documentation for SQL Server’s uniqueidentifier type says its ordering is not implemented by comparing bit patterns. That means RFC byte-order properties alone cannot establish how UUIDv7 will behave in a SQL Server index. Check the exact engine and version’s ordering rules, then test with the application’s actual write pattern.
Does PostgreSQL support UUIDv7?
PostgreSQL 18 documents the native uuid type and built-in uuidv4() and uuidv7() generators. Its UUID type stores the 128-bit value and can hold UUIDs of any version. The PostgreSQL 18 UUID type documentation and UUID functions documentation describe those features. The documented v7 generator uses a Unix timestamp with millisecond precision plus sub-millisecond timestamp and random data.
Rank #4
- Used Book in Good Condition
Do not generalize this into “PostgreSQL always supports UUIDv7.” Confirm the capabilities of the release you have deployed. If you store UUIDs in PostgreSQL, use the native uuid type where practical rather than text: the native value is 128 bits, while the RFC describes a text representation requiring 288 bits for a UUID.
Recommended Free Tools
What UUIDv7 reveals—and what it cannot protect
UUIDv7 includes a time component, so an ID may reveal an approximate creation time. Consider that exposure before putting such IDs in public URLs or logs where timestamps are sensitive. UUIDs should not be used as authorization secrets: an identifier is not a substitute for an access-control check or a secret designed to resist guessing. When unpredictability is required, RFC 9562 recommends a cryptographically secure pseudorandom number generator.
Quick Recap
How to make the choice safely
- Identify the need: Decide whether IDs must be generated independently across machines, whether time ordering helps, and whether timestamp leakage is acceptable.
- Check storage semantics: Confirm how your exact database release compares UUIDs and what its native UUID support provides.
- Verify generation: Use a correct implementation of the chosen version and an appropriate random source for its requirements.
- Test the workload: Compare the real write and index behavior in your environment rather than inferring a speedup from the UUID version alone.
- Plan compatibility: Check that clients, APIs, schema validation, and any existing sorting assumptions accept the version and ordering you choose.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
