UUID Generator
v4 is random. v7 is time-ordered.
v4 is random. v7 is time-ordered. If you're about to use a UUID as a primary key, that difference is the whole page.
Hit generate. Copy v7 for new tables. Copy v4 only when a spec still demands it.
How to use it
- v4 is 122 bits of random. Fine for IDs that are never used as a clustered index.
- v7 encodes a Unix timestamp in the high bits, so inserts append instead of scattering. That's what you want for a PK in Postgres, MySQL, and InnoDB.
- v1 is time + MAC. Don't use it if the machine identity shouldn't leak. v5 is a namespace hash, deterministic. Same input, same UUID, every time.
- A UUID is 36 characters with hyphens, 32 without, 16 bytes in binary. Store it as
uuid(Postgres) orBINARY(16), notVARCHAR(36), if you care about size.
When it breaks
- v4 as a primary key on a huge table is random page splits. The database gets slower as it grows. That's the bug, not “UUIDs are slow.”
- Uppercase vs lowercase hex is the same ID. Hyphens vs not is the same ID. Don't uniqueness-check the string form without normalizing.
- This is not a secret. A UUID is an identifier, not an auth token.
Configuration
Randomly generated UUID. Most common choice.
Collision Probability
Global risk (1B IDs)
Time to 1% Risk
at 1,000 IDs/second
Features
- UUID v4 (random) and UUID v7 (Unix-ms time-ordered) per RFC 9562
- Bulk generate, with v7 timestamps decoded from the first 48 bits
- Hyphens on/off; case toggle for systems that store 32 hex chars
- Collision notes: v4 is 122 random bits; v7 collisions are per millisecond
Common Use Cases
- Pick v7 as a SQL primary key when B-tree locality matters
- Keep v4 when the id must not leak creation time
- Seed fixtures with a known version nibble (4 or 7)
- See why v4 PKs fragment Postgres indexes under insert load
v4 is random. v7 is time-ordered.
v4 is random. v7 is time-ordered. If you're about to use a UUID as a primary key, that difference is the whole page.
Hit generate. Copy v7 for new tables. Copy v4 only when a spec still demands it.
v4 is 122 bits of random. Fine for IDs that are never used as a clustered index. v7 encodes a Unix timestamp in the high bits, so inserts append instead of scattering. That's what you want for a PK in Postgres, MySQL, and InnoDB.
v1 is time + MAC. Don't use it if the machine identity shouldn't leak. v5 is a namespace hash, deterministic. Same input, same UUID, every time. A UUID is 36 characters with hyphens, 32 without, 16 bytes in binary. Store it as uuid (Postgres) or BINARY(16), not VARCHAR(36), if you care about size.
Examples
550e8400-e29b-41d4-a716-446655440000018e5c4c-8b3a-7000-8000-000000000001550e8400e29b41d4a716446655440000Frequently Asked Questions
v4 is random. v7 is time-ordered. If you're about to use a UUID as a primary key, that difference is the whole page. v4 is 122 bits of random. Fine for IDs that are never used as a clustered index. v7 encodes a Unix timestamp in the high bits, so inserts append instead of scattering. That's what you want for a PK in Postgres, MySQL, and InnoDB. Copy v7 for new tables. Copy v4 only when a spec still demands it.
v1 is time + MAC. Don't use it if the machine identity shouldn't leak. v5 is a namespace hash, deterministic. Same input, same UUID, every time.
A UUID is 36 characters with hyphens, 32 without, 16 bytes in binary. Store it as uuid (Postgres) or BINARY(16), not VARCHAR(36), if you care about size. Uppercase vs lowercase hex is the same ID. Hyphens vs not is the same ID. Don't uniqueness-check the string form without normalizing.
v4 as a primary key on a huge table is random page splits. The database gets slower as it grows. That's the bug, not “UUIDs are slow.”
This is not a secret. A UUID is an identifier, not an auth token.
Tips
- Postgres: uuid v7 as PK, plus a created_at timestamptz if you need human time without decoding the id.
- Do not mix v4 and v7 in one unique column if you depend on sort order meaning created-at.
- UUIDs are not encryption and not password hashes.