Why v7 and ULID exist: index locality

v4 is 122 random bits: unpredictable and unordered. v7 (RFC 9562, 2024) leads with a 48-bit millisecond timestamp then 74 random bits, so a batch sorts lexically the same way it sorts by creation time. ULID (ulid/spec) encodes the same idea as 26 characters of Crockford's base32 instead of 32 hex digits.

A clustered or B-tree primary-key index (InnoDB, Postgres by default) inserts each row into whichever index page holds its key's range. A time-ordered id lands at the tail, extending the last page in place. A random v4 lands on a random page, forcing a split once that page fills, evicting whatever was cached there and leaving the index larger and more fragmented. So use v7 or ULID for a primary or sort key. v4 is fine for values only looked up by exact match: session tokens, one-off resource ids, idempotency keys.

One limitation: no monotonic counter, which some v7 and ULID libraries add. Two ids minted here in the same millisecond share a timestamp and are not guaranteed to sort in generation order. For a hard sub-millisecond guarantee, use a library implementing RFC 9562 §6.2 or ULID's monotonic variant.

Common problems

The ids are not sorting in the database. v4 is random by design and has no order to sort by. If you need ids that sort by creation time, that is what v7 and ULID are for, and switching is the whole fix.
A column is rejecting them. A UUID as text is 36 characters with the hyphens and 32 without. As a native uuid or BINARY(16) column it is 16 bytes. A CHAR(32) column silently truncates the hyphenated form.
They look predictable. v7 puts a millisecond timestamp in the leading bits on purpose, so consecutive ids share a prefix. That is the feature. Where unguessability matters, use v4, and never use either as a security token.
Two ids generated in the same millisecond came out in the wrong order. v7 orders to the millisecond and randomises below it, so ties inside one millisecond have no defined order. ULID has the same property.

Frequently asked questions

Is UUID v7 a standard, or a convention?

A standard. RFC 9562 obsoletes RFC 4122 and adds v7. Postgres 18 ships a native uuidv7(), and most mainstream languages have libraries for it.

What is the chance of two ids colliding?

Negligible. With v4's 122 random bits the birthday bound is roughly 2.6 quintillion ids before a 50% chance of one duplicate pair. v7 and ULID keep 74 and 80 random bits, refreshed every millisecond.

Why does ULID skip the letters I, L, O and U?

Crockford's base32 leaves them out so a misread character cannot resolve to a different valid one when someone retypes an id by hand. Case is not significant, in ULID or in UUID (RFC 9562 §4).

Do my settings stay in the link?

Version, count and the two toggles are kept in the URL. The generated ids are not: every visit mints a fresh batch.