Calling a library's UUID function feels like a finished design decision, but the version determines important behavior. Some UUIDs are random, some derive from names, and some preserve temporal ordering. They differ in privacy, repeatability, index performance, and ecosystem support. Choosing deliberately prevents an identifier from becoming an accidental source of leakage or database cost.
Version 4 is the familiar random choice
Version 4 fills most of the identifier with random bits. It is widely supported, easy to generate safely, and reveals no creation time or input name. For public identifiers and distributed record creation, it is a strong default when ordering is unnecessary.
Its randomness scatters inserts in ordered database indexes. At modest scale this may be irrelevant; at heavy write volumes it can increase page splits and reduce locality. The operational workload should decide whether that trade-off matters.
Time-based versions improve ordering
Older version 1 UUIDs combine a timestamp with a node identifier. They sort approximately by creation time but may expose when a record was created and information related to the generating node. Those properties can be undesirable in public identifiers.
Version 7 places a Unix timestamp in a modern time-ordered layout and fills the remaining space with randomness. It improves natural sorting and database locality without relying on a hardware address. Adoption is growing, but every producer, database, and client should support it before a system standardizes on it.
Name-based UUIDs are deterministic
Versions 3 and 5 derive a UUID from a namespace UUID and a name. The same inputs produce the same identifier, which is useful when several systems need a stable shared ID without a lookup service. Version 5 uses SHA-1, while version 3 uses MD5; these uses concern deterministic naming rather than password security.
The namespace prevents identical names in different domains from colliding. Inputs must be normalized consistently because a change in case, whitespace, or encoding creates a different result. Deterministic IDs may reveal that two records share the same source name, so consider privacy.
Do not invent a custom UUID version casually
Custom bit layouts and homemade random generators undermine the interoperability and analysis benefits of a standard format. If a system needs a different identifier, it may be clearer to choose another established scheme rather than produce strings that look like UUIDs but follow private rules.
Use maintained libraries backed by secure randomness and test that the expected version bits are present. Copying a UUID-shaped constant or relying on a non-secure pseudo-random function can create repeated values.
Sortability does not equal trustworthy chronology
A time-ordered UUID can help database indexes and rough ordering, but its embedded time comes from a machine clock. Clocks can drift or move backward, and concurrent generators can produce values within the same timestamp interval. Do not use UUID order as the sole source of legal or financial event chronology.
Store explicit creation timestamps and use domain-specific ordering when sequence matters. Identifier order is an optimization and convenience, not a complete event model.
Migration needs a compatibility plan
Changing UUID versions does not require changing the textual column shape, but assumptions may exist in validators, tests, sorting, and client code. Some code rejects unfamiliar versions even though it should accept any valid UUID. Other code may depend silently on randomness or time order.
Document accepted versions at API boundaries and separate identifier validation from business policy. A service may accept several versions while generating only one preferred version for new records.
Consider ecosystem and observability needs
An identifier chosen for database performance still travels through logs, queues, URLs, analytics systems, and support tools. Verify that every language and platform can parse and preserve the selected version. Operational tools should display it consistently and allow exact search without assuming sequential values.
Time-ordered identifiers can make logs easier to scan, while random values avoid exposing rough creation order. That trade-off belongs in the design decision alongside storage performance.
Match the version to the job
Choose version 4 for widely supported random identifiers, version 7 when time ordering and write locality matter, and name-based versions when deterministic mapping is the requirement. Avoid time-revealing formats when privacy matters and avoid deterministic formats when source values are sensitive.
Record the choice in architecture documentation and provide one shared generation library or service convention. Consistency prevents each team from quietly choosing a different version and creating avoidable validation and storage assumptions.
Revisit the choice when scale or privacy requirements change, but migrate carefully. Existing identifiers are durable references and normally should remain valid even after the preferred generation version changes.
Whichever version is selected, keep the generation API narrow and tested so future implementation changes do not silently alter required properties.
The best UUID version is the one whose properties are understood by the system. Once generation, storage, validation, and exposure rules are explicit, UUIDs remain simple to use while supporting very different architectural needs.