UUID & ID Generator

For most new applications: UUID v7 is the right default in 2025. It is a real ratified standard (RFC 9562, published in 2024), it is time-sortable, and it indexes cleanly in Postgres, MySQL, and every other B-tree database. The time-sortability is the unsung win — random UUID v4 keys scatter your B-tree because every insert hits a random index page, which means more page splits and worse cache locality on large tables. UUID v7 inserts append at the right edge, just like an auto-incrementing integer, but without the single-writer bottleneck.

UUID v4 is still appropriate for anything where you don't want the timestamp to leak. Session IDs, password reset tokens, OAuth state — these should be pure random. Using v7 here would leak the timestamp of token generation, which is usually fine but occasionally a problem (e.g., revealing when a user signed up via their referral ID).

nanoid is the right call when you need a URL-safe identifier shorter than UUID but with similar collision resistance. A 21-character nanoid has ~149 bits of entropy — comparable to UUID v4's 122 random bits but with 15 fewer characters. Use it for short shareable links, public IDs that show up in URLs, or any context where the human eye will read the ID.

ULID is what you reach for when you want both time-sortability and human readability. The 26-character Crockford Base32 alphabet excludes ambiguous characters (no I, L, O, U) so users can transcribe ULIDs from paper or phone calls without confusion. Great for support-facing reference IDs.

CUID was designed for horizontally scaled systems where multiple servers generate IDs concurrently and want collision resistance without coordination. In practice, UUID v4/v7 do the same job and are more widely supported, so CUID has lost market share. We include it because some Prisma / JavaScript ecosystem teams still use it heavily.

Short slugs exist for one use case: user-facing URLs where length matters more than collision resistance. Bitly. GitHub gists. Imgur. The pattern is always the same — generate slug, attempt insert with a UNIQUE constraint, retry on collision. An 8-character slug from a 36-character alphabet (a-z + 0-9) is ~41 bits of entropy. Fine until you reach hundreds of millions of records, at which point you bump to 10 or 12 characters.

A note on auto-incrementing integers. Sequence-generated IDs are still the right call when you genuinely need them — for example, invoice numbers users will see and reference. The trade-offs versus UUIDs: integers leak business volume (your /invoice/12345 tells a competitor you've issued ~12k invoices), make merging databases harder, and create single-writer bottlenecks at extreme scale. The modern pattern we ship in most builds is: UUID v7 primary key for the database, plus a separate user-facing short number (e.g., invoice 1024) generated by a sequence.

For deeper system design questions — distributed ID generation, sharding, primary-key strategy — see our API development services or book a 20-min architecture call. If you're working through build vs buy decisions, the right ID strategy is one of the foundational choices that determines what your data model can do at scale.