v4 or v7
v4 is 122 bits of pure randomness. Nothing in the value tells you when or where it was made. That suits identifiers exposed in public URLs, invite links, anything where the order of creation should stay hidden.
v7 puts a millisecond timestamp in the first 48 bits and fills the rest with randomness, so sorting the strings sorts by creation time. Use it for database primary keys, log identifiers, event ids — anywhere chronology helps. The trade is that the creation time is now readable from the value, so reach for v4 when that would leak something.
NIL is the all-zero value. It works as a placeholder for “nothing yet” in a column that refuses nulls.
As a database primary key
Using UUIDs instead of auto-increment integers lets several servers mint keys without coordinating, and an id in a URL no longer lets anyone guess the neighbouring rows.
The catch is v4’s randomness. A B-tree index is happiest when new keys land at the end; a v4 key lands anywhere in the middle, splitting pages over and over. Writes slow down and the index bloats as the table grows. v7 avoids this because values increase with time, so new keys always append. For a new table, v7 is the sane default.
Store them as BINARY(16) in MySQL or the uuid type in PostgreSQL. Keeping the 36-character string costs 20 extra bytes per row and makes every comparison slower.
Without hyphens
The hyphens are a display convention, not part of the value. File names, coupon codes and some APIs use the bare 32-character form. Uppercase is likewise only presentation — when comparing two UUIDs, lowercase both first.
Generating a batch
When this tool produces several v7s at once, they stay in the order they were generated. Everything made inside the same millisecond shares a timestamp, which would otherwise scramble the order, so part of the random field is used as a counter. Copy the list straight out and the sort order survives.