Online UUID v7 generator

UUID version 7 (UUIDv7) is a unique 128-bit identifier combining a timestamp and random data. Unlike older UUID versions, UUIDv7 can be sorted by time with millisecond precision, making it ideal for use in databases and distributed systems. It was standardised in RFC 9562 in May 2024, replacing the older RFC 4122.

While UUID v4 uses entirely random data, making it ideal for achieving maximum entropy, UUID v7 incorporates a 48-bit timestamp with millisecond precision. This makes UUID v7 time-sortable, providing better database index locality and improving query performance. UUID v4 is still preferred in contexts that require maximum entropy, such as for hashing salts and for generating context-free IDs for sensitive data. UUID v7, on the other hand, is better suited to database IDs and distributed systems.

UUID v7 has a specific bit structure. The first 48 bits contain a Unix timestamp in milliseconds. This is followed by a four-bit version field set to '7', a 12-bit random or counter section, a two-bit variant field set to '10', and finally a 62-bit random section. This combination of timestamp and randomness ensures time-sortability and uniqueness.

UUID v7 is recommended over older versions because it combines the advantages of sequential and random identifiers. It provides time-sortability without the privacy concerns associated with UUID v1 (which exposes MAC addresses) and offers better database performance than UUID v4. According to RFC 9562, UUID v7 should be used instead of UUID v1 and v6 where possible. UUID v7 is particularly valuable for database indexing and distributed systems.

UUID v7 was proposed as a draft standard in 2022 and officially became a standard in May 2024 with the publication of RFC 9562. This rendered the older UUID standard, RFC 4122, obsolete. The format had been under development and discussion for several years prior to standardisation.

UUID v7 improves database performance by providing better index locality. Since the timestamps in UUID v7 are sequential, new records are stored close to each other within database indexes. This reduces page splits and disk seeks, resulting in more efficient queries than with random UUIDs, such as v4, which can cause database records to become scattered. The performance difference can be quite significant in large databases.

Yes, UUID v7 is specifically designed for use as database primary keys. Unlike random UUIDs (v4), which can cause performance issues when used as primary keys due to poor index locality, the time-ordered nature of UUID v7 makes it perform well in databases. UUID v7 also does not require a central authority for generation, making it suitable for distributed databases and enabling generation prior to database insertion.

Yes, UUID v7 is binary-compatible with ULIDs (Universally Unique Lexicographically Sortable Identifiers). Both use a 48-bit timestamp in milliseconds since the Unix epoch and fill the remaining bits with random data. However, UUID v7 adds the version and variant bits required by the UUID specification, reducing the randomness from 80 bits to 74. At the bit level, all UUID v7s are valid ULIDs, but their string representations differ.

Yes, if revealing the creation time is a concern, the UUID v7 timestamps can be obscured while still providing the benefits of database performance. One approach is to perform a bitwise XOR operation with a secret UUID and the UUID v7, which discards the timestamp information and time-sortability, but maintains the database indexing benefits.