Should I use UUID v4 or v7 for a database primary key?
v7, in almost every case. v4 is fully random, so consecutive inserts land at random points in a B-tree index — that fragments the index, hurts cache locality and measurably slows inserts on a large table. v7 puts a millisecond timestamp in the leading bits, so new rows append at the end of the index like an auto-increment integer, while keeping the global uniqueness and unguessability that made you choose a UUID.
How likely is a UUID collision?
Negligible for v4: it carries 122 random bits, so you would need to generate about 2.7 × 10^18 UUIDs before reaching a 50% chance of a single collision. For context, generating a billion per second, that is roughly 85 years. You do not need to check for duplicates.
Does v1 leak my MAC address?
Not here. The v1 spec embeds the machine's MAC address, which is a permanent identifier — so a browser cannot and should not read it. This generator uses a random node ID with the multicast bit set, exactly as RFC 9562 prescribes when a hardware address is unavailable.
What is the nil UUID for?
It is the all-zeros UUID, defined by the spec as a valid "absence of value" sentinel — useful as a default in a non-nullable column or as a placeholder in tests, where it is instantly recognisable as not-a-real-id.