The encyclopedia · Software & IT · Technical decision · 2005–2026
UUID let any machine mint a globally unique ID with no central registry
A 128-bit identifier generated locally on any machine, with a collision chance so low that no registry or coordinator is ever needed.
Open Software Foundation · Internet Engineering Task Force
the move
Before UUIDs, if two systems each created a row, an ID, or a filename they had to ask a central authority for a number or risk colliding. Distributed databases and syncing apps could not coordinate forever.
RFC 4122 defined a 128-bit identifier any machine can generate on its own. Version 1 uses the timestamp plus the machine's MAC address; versions 3 and 5 hash a namespace plus a name; version 4 is random. All three run offline at millions per second.
Uniqueness follows from size plus generator identity, not from a registry; the standard states a UUID requires no central coordination. Because it is a fixed 128-bit value, every database, OS and web service stores it as one column and compares it as an integer.
why it works
- 128 bits is small enough to store but huge enough that two random picks are effectively distinct.
- Generation is local and offline, so there is no network hop, no rate limit and no single point of failure.
- The version bits let a reader tell whether an ID is time-based, name-based or random.
what transfers
When a name must be globally unique but nobody wants to run a coordinator, make it big and self-describing enough that local random generation is safe, and let anyone mint one offline.
what came after
UUIDs became the default key in PostgreSQL, the internal identifier in Mac and Windows GUID schemes, and the natural ID in distributed systems. RFC 4122 was followed by RFC 9562 in 2024, which added monotonic UUIDv6/v7 encodings and dusted off the older forms, but the philosophy of avoiding collisions by local generation never changed.
references
spotted an error? The archive wants to know.