What is a UUID?

• Version 1 (Time-based, with MAC address) UUIDs are generated using a combination of the current timestamp (100-nanosecond intervals since October 15, 1582) and the MAC address of the host computer.

  • Pros: Guarantees uniqueness across time and space, relatively fast to generate.

  • Cons: Poses a privacy risk as the host's MAC address can be extracted, and the non-standard timestamp ordering makes sorting them chronologically in databases inefficient.

• Version 2 (DCE Security) This version is a modification of Version 1, designed for use in the Distributed Computing Environment (DCE) security services. It replaces some of the timestamp and clock sequence bits with a local domain and identifier (e.g., POSIX UID/GID). It is rarely used and often not supported by standard libraries.

• Version 3 (Name-based, MD5 hash) UUIDs are generated by hashing a namespace identifier (itself a UUID) and a given name using the MD5 algorithm.

  • Pros: Generates the same UUID for the same input name and namespace, which is useful for creating deterministic identifiers.

  • Cons: MD5 is a weaker hash function than SHA-1, making Version 5 generally preferred.

• Version 4 (Randomly generated) This is the most widely used version. Most bits are generated using a cryptographically secure pseudo-random number generator (CSPRNG).

  • Pros: Offers maximum unpredictability and no information leakage (like MAC address).

  • Cons: Not chronologically sortable, which leads to poor database index performance (index fragmentation) when used as a primary key.

• Version 5 (Name-based, SHA-1 hash) Similar to Version 3, but uses the stronger SHA-1 hashing algorithm.

  • Pros: Provides deterministic and collision-resistant UUIDs based on a name, using a more secure algorithm than MD5.

  • Cons: Requires input data to generate, limiting its use case to scenarios where a consistent identifier is needed for a specific resource.

• Version 6 (Time-based, sortable) This newer version reorders the Version 1 timestamp fields so they are stored in a most-significant to least-significant order, making the resulting UUIDs lexicographically sortable by time. It also typically uses a random node ID to avoid privacy concerns.

  • Pros: Retains time-based properties while offering sortability and better database performance than Version 4.

  • Cons: The timestamp used (Gregorian calendar epoch) is less common than the Unix epoch.

• Version 7 (Unix Epoch time-based, sortable) A modern standard (defined in RFC 9562) that combines a 48-bit Unix epoch timestamp with random data.

  • Pros: Chronologically sortable, highly efficient for database indexing, uses the widely adopted Unix timestamp, and has no privacy issues. It is the recommended choice for most new applications.

  • Cons: As a newer standard, library support might still be growing compared to V1 and V4.

• Version 8 (Custom/Vendor-defined) This version is reserved for experimental or vendor-specific use cases. It has a defined version and variant field, but the remaining bits can be used in a custom manner as needed for specific application requirements.