Choosing the right identifier: UUID v4, UUID v7, ULID or NanoID
Identifier formats look interchangeable until they appear in a database index, a URL, a log line or a support ticket. UUID v4, UUID v7, ULID and NanoID can all be good choices, but they optimize for different tradeoffs.
UUID v4: boring, random and widely supported
UUID v4 is the default choice for many systems because it is random, familiar and supported almost everywhere. It does not reveal creation time and it is easy to generate independently across services.
The tradeoff is database locality. Purely random values can scatter inserts across an index, which may increase write amplification in large tables. For small and medium projects, this may never matter. For high-write tables, it can become noticeable.
UUID v7: time-ordered without giving up UUID compatibility
UUID v7 adds a timestamp-based prefix while keeping the UUID shape. That makes IDs roughly sortable by creation time and friendlier to database indexes than v4. It is a strong default for new systems that want UUID compatibility and better insertion locality.
Because v7 includes time information, it may reveal when a record was created. That is usually fine for internal database IDs, but it may matter for public URLs or privacy-sensitive workflows.
ULID: readable, sortable and copy-friendly
ULID is also time-sortable and uses a compact Crockford Base32 representation. It is easier to read aloud than a UUID and often looks cleaner in logs or admin screens.
The main downside is ecosystem support. UUIDs are built into more databases, ORMs and validation libraries. ULID works well when the application owns the format and the team wants sortable IDs with shorter strings.
NanoID: short IDs for URLs and product surfaces
NanoID is useful when the ID appears directly in a URL, invite code, share link or UI element. It can be much shorter than a UUID while keeping collision risk low when configured correctly.
Length matters. A very short NanoID may be fine for temporary UI state but risky for permanent records. Choose length based on expected volume, lifetime and the cost of a collision.
A simple decision guide
- Use UUID v4 when compatibility and randomness matter more than ordering.
- Use UUID v7 for new database records that benefit from time ordering.
- Use ULID when readable, sortable IDs are useful in logs or admin tools.
- Use NanoID for short public IDs, invite links and user-facing tokens.
- Avoid exposing any identifier if sequential timing or record volume is sensitive.