UUID / ULID Generator

UUIDv4 is 122 bits of randomness. Unpredictable and collision-free in practice, but random ordering means poor database index locality — inserts scatter across the B-tree, which degrades write performance and bloats indexes at scale.

UUIDv7 puts a millisecond timestamp in the high bits with randomness below. Still globally unique and effectively unguessable, but sorts chronologically, so inserts append to the index rather than scattering. For a new table with UUID primary keys, v7 is usually the better default.

A ULID is 128 bits like a UUID, but encoded in Crockford base32 — 26 characters instead of 36, case-insensitive, and free of the hyphens that make UUIDs awkward in URLs. It is also lexicographically sortable by time.

The tradeoff is ecosystem support: databases have native UUID types with efficient 16-byte storage, and ULIDs usually end up in a char column unless you convert. UUIDv7 gets you most of the ULID benefit while staying in the standard type.

A UUID is unique, not confidential. Anything reachable by guessing an identifier needs an authorization check — 'unguessable URL' is not access control, and identifiers leak through logs, referrer headers, and support tickets.

Sequential integers additionally leak volume and ordering, which is a business-intelligence problem more than a security one. UUIDs solve that but don't remove the need to check whether the caller may access the resource.