| Versions | v1 | v2 | v3 | v4 | v5 | v6 | v7 | v8 | empty-nil |
|---|---|---|---|---|---|---|---|---|---|
| Type | Time + Node (historically MAC) | DCE Security (UID/GID) | Name (MD5) | Random | Name (SHA-1) | Ordered time v1 | Time ordered + random | Custom / User-defined | Empty / Nil (all zeros) |
| Appeared | 1997 | 1997 | 1997 | 1997 | 1997 | ~2021 | ~2022 | ~2022 | 2005 |
| Deterministic? | No | No | Yes | No | Yes | No | No | Depends | Yes |
| Sortable? | Yes ~100 nanoseconds | Partial ~100 nanoseconds | No | No | No | Yes ~100 nanoseconds | Yes Millisecond | Depends | N/A |
| Secure? | MAC leak (historically) | Leaks IDs | MD5 | Yes | SHA-1 | Yes | Yes | Custom | No (not unique) |
| Typical Use | Distributed systems | Legacy DCE systems | Namespace-based IDs | General purpose (Recommended) | Stable API IDs | Database indexing | Latest most modern | Experimental, app-specific | Sentinel / “no value” / placeholder |
| Standardized | RFC 4122 -> RFC 9562 (July 2005 -> May 2024) | RFC 4122 -> RFC 9562 (July 2005 -> May 2024) | RFC 4122 -> RFC 9562 (July 2005 -> May 2024) | RFC 4122 -> RFC 9562 (July 2005 -> May 2024) | RFC 4122 -> RFC 9562 (July 2005 -> May 2024) | RFC 9562 (May 2024) | RFC 9562 (May 2024) | RFC 9562 (May 2024) | RFC 4122 -> RFC 9562 (July 2005 -> May 2024) |
| Deprecated? | Discouraged (not formally deprecated) | Effectively deprecated | Discouraged | No | No | No | No | No | No |
| Notes | Includes timestamp + Node (historically the MAC address). Ordered but exposes hardware info. | Embeds POSIX UID/GID + MAC address. Rarely supported and considered obsolete. | Deterministic, but MD5 is cryptographically broken. | Pure randomness (122 random bits). Extremely low collision probability. | Deterministic like v3 but uses SHA-1, which is no longer fully secure. | Improved v1 format with sortable structure + privacy-safe design. | Combines millisecond timestamps with strong randomness. Ideal for distributed systems. | Flexible GUID / UUID layout reserved for application-defined use. Not recommended for generic scenarios. | Not a real identifier, used to represent “no value”. Never generate or use it for uniqueness. |
GUID Version 1-8 - The Complete Comparison
Different GUID versions serve different purposes and are designed for specific use cases. This comprehensive comparison helps you understand the strengths, weaknesses and ideal applications for each version—from legacy v1 to modern v7 and everything in between.
Quick recommendation: For new projects use v7 if you care about database performance or you need sortable IDs (databases, logs). Or v4 for general-purpose full uniqueness without ordering requirements.
Understanding GUID versions
Each GUID (also known as a UUID) version is optimized for different requirements:
- Time-based versions (v1, v6, v7): include timestamps for natural ordering and database optimization
- Name-based versions (v3, v5): deterministic identifiers derived from names and namespaces
- Random version (v4): pure randomness for general-purpose unique identification
- Custom version (v8): application-defined layouts for specialized use cases
Complete version comparison table
The table below provides a detailed side-by-side comparison of all GUID / UUID versions, including their characteristics, security implications, and recommended use cases.
Choosing the right version
When selecting a GUID / UUID version for your project, consider these factors:
- Database performance: v6 and v7 provide natural ordering that improves index locality and reduces fragmentation
- Security and privacy: avoid v1 and v2 if MAC address exposure is a concern, v4 and v7 are privacy-safe
- Determinism: use v5 (or v3) when you need reproducible IDs from the same input
- Simplicity: v4 is the most straightforward—pure randomness with minimal configuration
- Modern standards: v6, v7 and v8 are part of RFC 9562 (2024), representing current best practices
Legacy vs modern versions
Historically, v1 and v4 dominated GUID / UUID usage under RFC 4122. Modern systems increasingly adopt v7 for its superior database characteristics while maintaining strong security and uniqueness guarantees.
Version encoding in GUIDs / UUIDs
The version number is encoded in the first hexadecimal digit of the third group in the canonical 8-4-4-4-12 format:
Canonical format: 8-4-4-4-12
Example: f47ac10b-58cc-4372-a567-0e02b2c3d479
Layout: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
^ ^
| └─ N = Variant (layout family)
└────── M = Version (1-8)
In the example above, the version is 4 (v4 = random). The variant is 3 which maps to 0011 in binary, indicating the RFC 4122/9562 standard layout.
Frequently Asked Questions
All three include timestamps but differ in layout and privacy. V1 uses MAC addresses (privacy risk) and has poor string sortability. V6 reorders v1's timestamp for better sorting but still includes node information. V7 uses Unix epoch timestamps with random data, offering the best combination of sortability, privacy and database performance.
UUID v4 is popular because it's simple, secure, and widely supported. It uses 122 bits of randomness, making collisions statistically impossible in practice. It doesn't leak any metadata (timestamps, MAC addresses), has no configuration requirements, and works in any environment. It's the "safe default" choice when you don't need special features.
Yes, for new projects. V1 can leak MAC addresses and creation timestamps, creating privacy and security concerns. V2 (DCE Security) is rarely implemented, poorly documented, and embeds OS-level identifiers like POSIX UID/GID. Both are considered legacy formats. Use v7 for time-based IDs or v4 for random IDs instead.
Deterministic UUIDs generate the same identifier from the same input every time. V3 uses MD5 hashing (cryptographically broken, avoid it). V5 uses SHA-1 hashing (better but not fully secure). Both are useful for creating stable IDs from names (e.g., URL namespaces), but should not be used where cryptographic security is required.
UUID v7 has a timestamp prefix that makes IDs naturally ordered by creation time. This improves database index locality, reduces page splits in B-tree indexes, and speeds up inserts and range queries. V4's random nature causes index fragmentation and poor cache performance at scale. For high-volume systems, v7 can significantly improve performance.
GUID / UUID v8 is a custom/application-defined format introduced in RFC 9562. It allows you to design your own 128-bit layout while maintaining GUID / UUID structure. However, it's not recommended for general use because it lacks standardization, has limited library support and creates interoperability challenges. Use v8 only if you have very specific requirements that no other version addresses.
Yes, you can mix GUID / UUID versions in the same system, they all use the same 128-bit format. However, mixing versions can complicate sorting, validation and debugging. It's best to standardize on one version per use case (e.g., v7 for database records, v4 for full randomness). Document your choices clearly for maintainability.
Yes, all GUID / UUID versions share the same 128-bit structure and
8-4-4-4-12 format. Systems that store or transmit GUIDs / UUIDs as strings or binary can handle any version. However, functionality like ordering or determinism is version-specific. RFC 9562 (which introduced v6, v7, v8) maintains full backward compatibility with RFC 4122 (v1-v5).Conclusion
Choose your GUID / UUID version based on your specific requirements. For most modern applications, v7 offers the best balance of performance, security, and functionality. When in doubt, v4 remains a solid, battle-tested choice for general-purpose unique identification.
Learn more
These articles expand on related concepts, formats and practical considerations.