UUID Generator
Generate v4 random and v7 time-ordered UUIDs in bulk, with the format variants tooling expects and an explanation of when v7 is the better choice.
Result
About UUID Generator
UUIDs let independent systems mint identifiers without coordinating. Version 4 is pure randomness; version 7 prefixes a timestamp so identifiers sort in creation order - which matters a great deal once they become database primary keys.
Storing identifiers efficiently
A UUID is 128 bits. Stored as a 36-character string it costs 36 bytes plus overhead and compares character by character; stored as 16 binary bytes (BINARY(16), PostgreSQL uuid) it costs 16 and compares as two machine words. At tens of millions of rows the difference is measured in gigabytes of index. If human readability matters at the boundary, convert at the edge and keep the binary form in storage.
v4 or v7 for a primary key
Random v4 keys insert at random positions in a B-tree index, fragmenting pages and hurting write throughput and cache locality. v7 keys are monotonically increasing, so inserts land at the end of the index like an auto-increment integer while keeping global uniqueness. The trade is that v7 reveals when the record was created.
Common use cases
- Seeding test data or configuration that needs unique identifiers.
- Generating a correlation ID for tracing a request across systems.
- Creating device or session identifiers offline.
Edge cases and gotchas
- Do not use a UUID as a security token unless it is v4 - v7 is partially predictable.
- Storing UUIDs as text costs 36 bytes versus 16 as binary; at scale that is real index space.