Choose an ID for the job

Version 4 prioritizes random identifiers

UUID v4 carries random bits plus fixed version and variant bits in the standard UUID structure. It is widely recognized and independent of a central allocator, but random insertion order may not be ideal for every database index.

The generator uses a maintained UUID implementation, which obtains secure randomness and can use native support. A small uniqueness smoke test is useful for finding integration mistakes, but it is not a mathematical proof that collisions cannot happen.

Version 7 carries time

UUID v7 places a Unix timestamp in milliseconds near the start of the UUID. It can improve time-oriented ordering, subject to the comparison semantics of your database. It also reveals approximate creation time, which can be undesirable for publicly visible identifiers.

Do not treat ordering as a distributed consensus clock. Clock differences, library behavior and same-millisecond generation matter. Confirm the guarantees of the implementation before using IDs as the sole source of business-event order.

v4: random-oriented, standardized UUID form
v7: timestamp-oriented, standardized UUID form
NanoID: configurable length with a compact alphabet

Compact IDs require a collision budget

NanoID trades a configurable alphabet and length for a shorter string. Reducing length reduces the possible identifier space. This tool offers validated URL-safe or alphanumeric presets, with bounds intended to avoid accidental huge output.

Keep uniqueness constraints and collision handling where your application needs them. An identifier is not an authorization token: a user must still be authorized to access the resource, even if its ID is difficult to guess. Use the separate secret generator when the value itself grants access.

Continue reading

• How much randomness does an API key need?
• Make fixtures repeatable and clearly synthetic