What Is a UUID and Why Your Database Needs One

What a UUID actually is

If you have ever seen a string like 550e8400-e29b-41d4-a716-446655440000, you have seen a UUID. It is not a random jumble of characters. It is a standardized 128-bit identifier governed by RFC 4122, used in databases, APIs, distributed systems, and session management. Every major platform — PostgreSQL, MongoDB, MySQL 8, AWS, and even blockchain — supports UUIDs natively.

A UUID is 36 characters long, split into five groups separated by hyphens. The format is 8-4-4-4-12 hexadecimal digits. Despite looking like text, it stores 128 bits of information. The total address space is 2^128, or roughly 3.4 × 10^38 unique values. To put that in perspective: if you generated a billion UUIDs every second for a hundred years, the probability of a collision would still be vanishingly small.

Why databases prefer UUIDs over integers

The main reason developers use UUIDs is independence. An integer primary key requires a central authority — usually the database — to assign the next value. In a distributed system with multiple nodes, shards, or microservices, coordination becomes a bottleneck. UUIDs solve this because any node can generate a valid, globally unique identifier without talking to any other node.

• No central counter needed
• No locking or contention between distributed nodes
• Easy to shard databases across regions

UUIDs also prevent enumeration attacks. An auto-incrementing integer like /user/123 invites scraping. A UUID like /user/550e8400-e29b-41d4-a716-446655440000 does not.

UUID versions: when v1, v4, or v7 makes sense

There are multiple versions of UUIDs. Version 1 combines a timestamp with the machine's MAC address. That makes it sortable by time and traceable to a physical device. Version 4 is pure randomness — all 122 random bits, with 6 reserved bits for the version and variant fields. Most systems today use version 4 because it is completely opaque: you cannot derive the creation time or the originating machine from the ID itself, which improves privacy.

Some databases are experimenting with UUIDv7 (draft RFC), which encodes a timestamp prefix for sortability while keeping randomness in the suffix. This solves the index fragmentation problem of v4 without sacrificing the opacity that makes UUIDs useful.

The hidden cost of UUIDs

UUIDs are not free. They are four times larger than a 32-bit integer and twice the size of a 64-bit integer. In a table with a billion rows, that adds up to gigabytes of extra storage and index size. They also fragment B-tree indexes because random insertions are distributed across the whole keyspace, unlike sequential integers which append at the end.

Mitigations include:

• Using UUIDv7 for sortability and better spatial locality
• Storing UUIDs as BINARY(16) in MySQL or UUID in PostgreSQL instead of VARCHAR(36)
• Using UUIDv4 only for external-facing identifiers, keeping internal surrogate keys as integers

Security: why randomness matters

Security matters when generating UUIDs. A UUID generator that uses Math.random() is pseudo-random and potentially predictable if an attacker knows the seed. Always use a cryptographically secure source of randomness. In the browser, this means crypto.getRandomValues().

The DevUtils UUID Generator calls this API directly, producing RFC 4122 v4 UUIDs that are suitable for production use in databases, APIs, and session identifiers. No server is involved, so your identifiers never leave your machine.

Start using UUIDs today

If you are building a distributed application, do not wait until you need to shard your database or spin up a second region. Use UUIDs from the start. The DevUtils UUID Generator lets you create up to 1,000 v4 UUIDs instantly, entirely offline, with zero setup. Copy them to your clipboard and use them in migrations, seed data, or API payloads immediately.