Definition
Lexicographical order (also called lexicographic order or lexical order) is the ordering of strings based on the alphabetical sequence of their characters — the same way words are ordered in a dictionary. When applied to UUID strings, lexicographical sorting means comparing the characters of two UUIDs left to right, character by character, until a difference is found.
This matters for UUIDs because database indexes sort entries, and the sort order of a primary key directly affects insert and query performance.
UUID v7 and lexicographical order
UUID v7 is deliberately designed so that lexicographical order equals chronological order: sorting v7 UUIDs as plain strings produces the same sequence as sorting by creation time.
This works because UUID v7 places its 48-bit Unix millisecond timestamp in the most significant bits (the leftmost characters of the string). Since earlier timestamps have smaller numeric values, and hexadecimal digits sort in their natural value order (0 < 1 < … < 9 < a < b < … < f), a simple left-to-right string comparison gives chronological order.
Example — three v7 UUIDs generated in order:
018c4a14-2d91-7abc-8def-000000000001 ← earliest
018c4a14-2d92-7abc-8def-000000000002
018c4a14-2d94-7abc-8def-000000000003 ← latest
Sorting these as strings gives the correct chronological sequence.
UUID v4 and lexicographical order
UUID v4 is fully random — its 122 bits carry no timestamp. Sorting v4 UUIDs lexicographically produces a random order with no relation to creation time.
This is a significant database performance issue: each new v4 UUID inserts at a random position in a B-tree index rather than at the end. This causes page splits and destroys cache locality — the two main performance bottlenecks for UUID primary keys in write-heavy tables.
Database index implications
B-tree indexes (used by PostgreSQL, MySQL, SQL Server, SQLite) work best when new values are appended to the end of the range. Auto-incrementing integers do this naturally. UUID v7 achieves the same property through its timestamp prefix.
| UUID type | Insert pattern | Index behavior |
|---|---|---|
| v4 (random) | Random position | Page splits, poor cache locality, slower writes |
| v7 (time-ordered) | Near the end | Sequential appends, good cache locality, fast writes |
For a write-heavy table with millions of rows, this difference can be 2–5× in insert throughput.
Lexicographical order in different storage representations
Lexicographical sort order holds for the standard string representation (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx). If you store UUIDs as binary (BINARY(16) or PostgreSQL’s native uuid type), the sort order is based on byte comparison — which is equivalent and also gives chronological order for v7 values stored with the timestamp bytes first.
SQL Server exception: SQL Server’s uniqueidentifier type stores GUID bytes in a non-standard order. UUID v7 values do not sort chronologically as uniqueidentifier without a byte-swap transformation. See GUID for details.
Monotonicity within the same millisecond
Two UUID v7 values generated in the same millisecond share the same timestamp bits. Without additional care, their lexicographic order would be random within that millisecond.
RFC 9562 §6.2 recommends a per-millisecond monotonic counter: a value that increments with each UUID generated within the same millisecond, and resets when the clock advances. This guarantees that even same-millisecond UUIDs sort in generation order.
This tool implements the RFC 9562 monotonic counter — v7 UUIDs generated here always sort in generation order.
ULID and lexicographical order
ULID (Universally Unique Lexicographically Sortable Identifier) was designed with the same goal as UUID v7: lexicographically sortable by creation time. ULIDs use Base32 encoding instead of hexadecimal and produce a 26-character string instead of 36.
For most database applications, UUID v7 is the better choice because it has RFC standardisation and native database type support. See UUID vs ULID for the comparison.
Related terms
- UUID — the full identifier definition
- Entropy — the randomness in the non-timestamp bits of UUID v7
- Collision — why the random suffix still avoids collisions despite the shared timestamp prefix
Generate a lexicographically sortable UUID v7 with the UUID v7 generator.
Frequently asked questions
What does lexicographical order mean for UUIDs?
Lexicographical order is alphabetical sort order applied to strings. UUID v7 is designed so that sorting UUIDs as plain strings (lexicographically) produces the same sequence as sorting by creation time. This is why v7 is index-friendly in databases — string comparison gives chronological order.
Should I use v4 or v7?
Use v7 for database primary keys (time-sortable, index-friendly) and v4 for anything where creation order could leak information, like tokens or share links.
Should I use ULID or UUID v7?
UUID v7 is the safer default for database-backed applications — it has RFC standardisation, native PostgreSQL uuid type support, and growing ORM integration. ULID produces shorter 26-character strings and is a reasonable choice when IDs are primarily used as strings in logs or APIs and database native types are not a concern.