UUID v4 Explained: Why Random IDs Beat Auto-Increment

What a UUID v4 actually is, why the collision risk is negligible, and the concrete situations where it beats a simple auto-increment integer ID.

A UUID v4 is a 128-bit identifier generated almost entirely from random bits, formatted as 32 hex characters split into 5 groups (e.g. 3fa85f64-5717-4562-b3fc-2c963f66afa6). The '4' marks the version, and it means the ID carries no information at all about when, where, or by what it was created — which is exactly the point.

Isn't there a risk two IDs collide?

Technically yes, practically no. A UUID v4 has 122 random bits (6 bits are fixed to mark the version and variant), giving about 5.3 x 10^36 possible values. You would need to generate roughly 2.71 quintillion UUIDs before there is a 50% chance of a single collision. For essentially every real application, that risk is smaller than the odds of a hardware failure corrupting the data anyway.

Why not just use 1, 2, 3… like a database auto-increment?

An auto-increment integer works fine inside a single database, but it leaks information and breaks the moment your system grows. Sequential IDs let anyone guess neighbouring records just by changing a number in a URL (/orders/1042 → /orders/1043), reveal your approximate signup or order volume to competitors, and cannot be safely generated by two different servers at the same time without a shared counter — which becomes a bottleneck the moment you scale horizontally.

When a UUID is clearly the better choice

Any system with multiple independent writers (microservices, offline-first mobile apps, distributed databases) benefits the most, since every node can generate a valid, unique ID with zero coordination and zero central counter. It is also the right call whenever an ID might become user-facing — order references, API resource IDs, file names — where you don't want it to be guessable or to reveal sequence information.

When an integer is still the better choice

For a small, single-writer application where IDs never leave the database and you need the smallest possible storage footprint and the fastest index lookups, a plain auto-increment integer (or its ordered cousin, UUID v7) is still simpler and faster. UUID v4's randomness is also its main downside for indexing: because the values are unordered, they fragment a B-tree index far more than a sequential ID would.

Our UUID generator produces valid, RFC 4122-compliant v4 UUIDs instantly and in bulk, entirely in your browser — useful for test fixtures, mock data, or simply picking a safe unique ID without spinning up a database.