Recommended for time-ordered IDs: GUID / UUID v7 is the preferred choice for applications requiring time-based sortability without sacrificing decentralized generation. It's ideal for database primary keys, event streams, and distributed log aggregation.
Version status and history
GUID / UUID v7 was officially standardized in RFC 9562 in May 2024.
V7 is a modern, actively recommended GUID / UUID version with no deprecation concerns. It was specifically designed to address the limitations of older versions by providing time-based sortability (like v6) without exposing MAC addresses, and by offering better database performance than pure random identifiers (like v4).
For non-time-ordered identifiers, consider v4 (random).
Advantages of GUID / UUID v7
- Time-ordered (practical sorting): the leading millisecond timestamp makes v7 GUIDs / UUIDs generally sortable by creation time when stored/compared in standard GUID / UUID byte order.
- Great for databases: tends to reduce random insert patterns compared to v4. Improving index locality in many B-tree setups.
- Distributed-friendly: can be generated independently on many nodes without coordination or a centralized service.
- Low collision risk: combines a timestamp prefix with substantial randomness (remaining bits), making duplicates extremely unlikely with a proper generator.
- Simple to validate: the version nibble is always
7 and the variant bits indicate the RFC-defined layout (most commonly 10xx in the canonical string as 8-b). - Works well for event streams: useful for IDs that are frequently listed “newest first” or partitioned by time windows.
- Modern standard: standardized in RFC 9562 (which updates and supersedes RFC 4122).
Warnings and considerations
- Timestamp disclosure: v7 encodes an approximate creation time (millisecond epoch). Which can leak timing metadata in public IDs or URLs.
- Ordering is “best effort”: within the same millisecond, ordering depends on random/counter behavior (varies by implementation), so strict monotonicity is not guaranteed everywhere.
- Clock issues matter: skewed clocks, time going backwards or low-resolution timers can reduce ordering quality and may require special handling in high-throughput generators.
- GUID byte-order pitfalls: some platforms (notably certain “GUID” binary layouts) reorder bytes when storing/serializing. That can break expected “sort by time” behavior unless you store/compare in standard GUID / UUID byte order.
- Not a security token: v7 is an identifier, not an access secret. Don't treat it as unguessable authorization (even though it has randomness).
- Implementation differences: some generators may use part of the random region as a counter for monotonicity; others use purely random bits. Treat internal subfields beyond version/variant as opaque.
Technical details
Bit layout: a GUID / UUID is 128 bits written in a canonical 36-character string format with 32 hexadecimal digits plus 4 hyphens (8-4-4-4-12). For v7, the first 48 bits contain a Unix Epoch timestamp in milliseconds, followed by reserved version and variant bits, and the remaining bits are used for uniqueness (typically random, but may include a counter).
Generation algorithm: the leading 48 bits encode the current Unix Epoch timestamp in milliseconds (big-endian). The remaining bits (after version and variant) are filled with random data or a combination of random data and a counter to ensure uniqueness within the same millisecond.
Field structure (timestamp-based)
Field Name Bits Hex Digits Description
─────────────────────────────────────────────────────────────────────────
unix_ts_ms 48 12 Unix Epoch timestamp in milliseconds (big-endian)
ver 4 1 4-bit version field (0111 = 7 in hex)
rand_a 12 3 12 random bits
var 2 ~0.5 2-bit variant field (10 = RFC 4122 variant)
rand_b 62 ~15.5 62 random bits (or counter + random)
unix_ts_ms (48 bits): the first 48 bits encode a Unix Epoch timestamp in milliseconds. This provides a range from the Unix Epoch (January 1, 1970) to approximately the year 10889, offering over 8900 years of timestamp space.
ver (4 bits): the version field is set to 0111 (7 in hex), identifying this as a v7 UUID.
rand_a (12 bits): 12 random bits immediately following the version field.
var (2 bits): the variant bits are set to 10, indicating RFC 4122 compliance.
rand_b (62 bits): 62 bits of randomness or a combination of counter and random bits. Some implementations use a portion of this field as a monotonic counter to ensure strict ordering within the same millisecond on the same node. The specific layout is implementation-defined.
Try our GUID / UUID Inspector to decode and visualize the timestamp and bit-level structure of v7 GUIDs / UUIDs.
Format and structure
GUID / UUID v7 uses the standard 8-4-4-4-12 canonical format with 32 hexadecimal digits separated by hyphens (36 characters total).
Canonical format: 8-4-4-4-12
Example (v7): 018f3f5e-1c2d-7a9b-8f10-3c4d5e6f7a8b
Layout: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
^ ^
| └─ N = Variant: is typically 8, 9, a or b (RFC variant)
└────── M = Version: first hex digit of the 3rd group is "7" for v7
Practical rule: in the canonical string, the version is encoded as the first hex digit of the third group. For v7 it is 7. The variant is indicated by the high bits of the fourth group (often rendered as 8-b in hex for the common standard variant). The first 12 hex digits encode the Unix Epoch timestamp in milliseconds.
Ordering behavior: because the timestamp is stored at the front (big-endian), sorting v7 GUIDs / UUIDs in their standard byte/string form generally groups them by time. Within the same millisecond, order is influenced by the remaining bits (random and/or counter), so ordering is typically time-correlated, not perfectly sequential.
Randomness: after the 48-bit timestamp and the version/variant fields, a GUID / UUID v7 has 74 bits of randomness (or counter + random bits).
This provides 2⁷⁴ possible combinations within the same millisecond.
That's approximately:
1.9 × 10²² unique values per millisecond
To put this into perspective:
- Even if you generated 1 trillion GUIDs / UUIDs within the same millisecond, the probability of a collision is still extremely low (less than 1 in 18 million).
- The timestamp component (48 bits) provides uniqueness across different milliseconds, spanning over 8900 years from the Unix Epoch.
- Combined with the timestamp, v7 offers both temporal ordering and collision resistance, making duplicates effectively impossible in practical scenarios.
Frequently Asked Questions
GUID / UUID v7 is a time-ordered identifier that combines a 48-bit Unix Epoch timestamp in milliseconds with random bits to create globally unique identifiers. The timestamp is stored at the beginning (big-endian), making v7 GUIDs / UUIDs roughly sortable by creation time. This design improves database performance by reducing index fragmentation while maintaining decentralized generation.
Use v7 for
database primary keys,
event streams,
distributed log systems and any application where time-based ordering improves performance or usability. It's ideal when you need both global uniqueness and approximate chronological sorting. For identifiers without time ordering, use
v4.
Both v7 and
v6 are modern time-ordered GUIDsd / UUIDs, but they differ in timestamp format and precision. V7 uses
Unix Epoch milliseconds (48 bits, human-readable), while v6 uses a reordered Gregorian timestamp with 100-nanosecond precision (60 bits, like v1 but reordered). V7 offers simpler timestamp extraction and is the newer standard (
RFC 9562), while v6 provides higher temporal resolution. Both are privacy-safe and don't embed MAC addresses.
Yes, v7 GUIDs / UUIDs are roughly sortable by creation time. The leading 48-bit timestamp ensures that UUIDs generated at different milliseconds will sort chronologically. Within the same millisecond, ordering depends on the random or counter bits, so it's "best-effort" ordering rather than strict monotonicity.
Yes, the first 48 bits encode the Unix Epoch timestamp in milliseconds, which can be extracted to determine when the GUID / UUID was generated (within millisecond precision). If timestamp privacy is important (e.g., public-facing URLs or API keys), use
v4 instead, which contains no temporal information.
The collision risk is extremely low. Within the same millisecond, v7 has 74+ bits of randomness (or counter + random bits), providing trillions of unique values per millisecond. Across different milliseconds, the timestamp ensures uniqueness. Even in high-throughput distributed systems, collisions are effectively impossible with proper random number generators.
Yes, and it's
highly recommended for databases. V7's time-ordered structure reduces index fragmentation and improves write performance compared to random
v4 GUIDs / UUIDs. Most modern databases (PostgreSQL, MySQL, etc.) benefit from sequential-ish inserts. V7 combines the best of both worlds: decentralized generation and time-based locality.
As of 2024-2026, v7 support is growing in popular libraries:
- JavaScript/Node.js: Use
uuid npm package v9+: uuid.v7() - Python:
import uuid; uuid.uuid7() (Python 3.13+) or use third-party libraries like uuid6 - Java: Use third-party libraries like
com.github.f4b6a3:uuid-creator - C#: Use
Guid.CreateVersion7() (planned in .NET 9+) or third-party libraries - Go:
uuid.NewV7() (with google/uuid package v1.4+) - Rust:
Uuid::now_v7() (with uuid crate v1.3+)
No, v7 GUIDs / UUIDs should not be used as security tokens, session IDs, passwords or cryptographic keys. The embedded timestamp makes them partially predictable, and they are not designed for cryptographic security. For security-sensitive applications, use dedicated cryptographic token generation functions with sufficient entropy (256+ bits).
Clock drift or time going backwards can affect ordering quality. Most robust v7 implementations use a monotonic counter or last timestamp tracking to ensure new GUIDs / UUIDs are always greater than previous ones generated on the same node. If the clock goes backwards, the generator can either wait, use the last known timestamp, or increment a counter. Implementation strategies vary, consult your library's documentation.
Conclusion
GUID / UUID v7 is the recommended choice for modern applications requiring time-ordered identifiers with decentralized generation. It combines the best features of v6 (time-ordering) and v4 (privacy and simplicity), making it ideal for databases, event streams and distributed systems. Use v7 when time-correlation is helpful and prefer v4 when you need to avoid exposing creation time in the identifier.