UUID v4 is the default most people reach for, and it's a fine default: 122 bits of randomness, a format every database and language understands natively, and collision odds low enough to not think about. The cost is length — 36 characters, mostly hyphens and hex — which is annoying in a URL or a support ticket someone has to read aloud.
Nanoid trades some of that for compactness: a shorter, URL-safe string with a configurable alphabet and length, at the cost of not being a format databases treat specially. That's the real tradeoff — not security, but whether the ID needs to be a first-class type in your schema or just an opaque token.
A practical rule: reach for UUID v4 for anything that's a primary key or gets stored in a UUID-typed column, and reach for a shorter random ID for anything user-facing — short links, invite codes, session tokens shown in a URL. Optimize for what a human or a URL bar has to deal with, not for entropy you don't need.
More from the blog
What We're Building Next: dont-break-prod
A PR-review training game for payments engineers — read the contract, read the code, decide if it's safe to ship.
5 Habits for Debugging Messy JSON Payloads Faster
The difference between a two-minute payload review and a twenty-minute one usually comes down to a few small habits.
SQL Formatting Conventions That Make Code Review Easier
A query that's easy to review is one where the diff shows the actual change, not a reflow of every line around it.