Randomness and ordering solve different problems
UUID v4 is random and reveals no creation time, but random inserts can scatter writes across a large database index. UUID v7 and ULID put a millisecond timestamp near the front, improving natural sort order while exposing approximate creation time.
Ordering does not guarantee monotonicity
Two IDs generated in the same millisecond need an additional strategy if their lexical order must exactly match generation order. Clock rollback, multiple machines, and implementation-specific random fields can also affect ordering.
Treat IDs as identifiers, not access controls
An unpredictable ID reduces casual guessing but does not authorize access. Apply authentication and object-level authorization regardless of the identifier format, and avoid encoding private meaning in IDs.
Quick comparison
| Format | Shape | Ordering | Best fit |
|---|---|---|---|
| UUID v4 | 128-bit UUID, 36-character canonical text | Random | Maximum compatibility and no embedded time |
| UUID v7 | 128-bit UUID, 36-character canonical text | Time-ordered by design | Database locality with UUID tooling |
| ULID | 128 bits, 26 Crockford Base32 characters | Lexically time-sortable | Compact readable strings with ULID ecosystem support |