How many UUIDs?

About UUID v4

A UUID v4 is a 128-bit randomly generated identifier in the format xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx. The probability of a collision is astronomically low, making UUIDs safe for use as unique keys in databases, distributed systems, and APIs.

About the UUID Generator

A UUID (Universally Unique Identifier) is a 128-bit identifier formatted as 8-4-4-4-12 hexadecimal characters separated by hyphens (e.g. 550e8400-e29b-41d4-a716-446655440000). UUIDs are designed to be globally unique without central coordination — the probability of two randomly generated UUID v4s being identical is negligibly small, making them safe for use as database primary keys, correlation IDs, and file names across distributed systems.

UUID versions explained

UUID v1 — based on timestamp + MAC address. Sortable but leaks hardware information.
UUID v4 — 122 random bits. Most widely used. Generated here.
UUID v5 — SHA-1 hash of namespace + name. Deterministic: same input always gives same UUID.
UUID v7 — millisecond timestamp prefix + random bits. Sortable and database-efficient. The modern preferred standard.

UUIDs vs auto-increment IDs

Auto-increment integers are compact and fast to index, but expose data volume and create merge conflicts in distributed systems. UUIDs are opaque, merge safely across systems, and can be generated client-side without a database round-trip — at the cost of larger storage (16 bytes vs 4-8 bytes for integers).

UUID in database design

Choosing between UUID and auto-increment primary keys involves trade-offs in storage, performance, and scalability. UUIDs enable distributed ID generation (no database round-trip needed), make IDs harder to guess (security benefit), and simplify data merging across systems. The performance penalty of UUID v4 as a primary key in indexed B-tree databases is real but manageable; UUID v7's ordered structure largely eliminates it.

Storage — UUID is 16 bytes (stored as binary) or 36 bytes as a string; integer is 4-8 bytes
Index efficiency — random UUIDs (v4) cause B-tree index fragmentation; sequential (v7) does not
Security — UUIDs are opaque: you cannot enumerate records by incrementing an ID
Distributed generation — UUIDs can be generated on the client or any node without database coordination

Frequently Asked Questions

What is a UUID used for?

UUIDs are used as unique identifiers in databases, distributed systems, file names, session tokens, and API resources. They are globally unique without requiring any central authority, making them ideal for systems where multiple nodes generate IDs independently or where IDs are created before database insertion.

What is the difference between UUID v4 and UUID v7?

UUID v4 is 122 random bits with no time component — completely random and not sortable. UUID v7 embeds a millisecond Unix timestamp in the first 48 bits followed by random bits, making UUIDs sortable in creation order. v7 is significantly more efficient as a database primary key due to better index locality.

Can two UUID v4s ever be the same?

Technically yes, but the probability is negligible. With 2 to the power of 122 possible values, you would need to generate about 2.7 x 10 to the power of 18 UUIDs to have a 50% chance of a collision — more than a billion per second for 85 years.

Should I use UUIDs or auto-increment IDs?

Auto-increment integers are more efficient (4-8 bytes vs 16 bytes), easier to debug, and have better default index performance. UUIDs are better when multiple nodes generate IDs independently, when hiding data volume matters, or when client-side ID generation is needed. UUID v7 offers the best balance for new applications.

How do I generate a UUID in code?

Python: import uuid; str(uuid.uuid4()). JavaScript (modern): crypto.randomUUID(). Node.js (older): require("crypto").randomUUID(). Java: UUID.randomUUID().toString(). PostgreSQL: SELECT gen_random_uuid().