What a UUID actually is
A UUID (Universally Unique Identifier, also called GUID on Windows) is a 128-bit number represented as 32 hex digits in five groups separated by hyphens: 8-4-4-4-12.
550e8400-e29b-41d4-a716-446655440000
The format is defined by RFC 4122. The third group encodes the version (4 in 41d4), and the fourth group encodes the variant (the leading bits of a716 tell you this is RFC 4122 compliant).
UUID v4: the one you should use
Version 4 UUIDs are randomly generated. 122 of the 128 bits are random (6 bits encode version and variant). With crypto.randomUUID() the source of randomness is the OS-level cryptographically secure random number generator — the same one used for TLS session keys.
The probability of generating two identical v4 UUIDs in your lifetime, even generating millions per day, rounds to zero. The birthday paradox math: you need to generate roughly 2.7 × 10¹⁸ UUIDs before the collision probability reaches 50%.
UUID v1: useful for event ordering
Version 1 encodes the current timestamp (in 100-nanosecond intervals since 15 October 1582) plus a node ID (traditionally the MAC address). Because they include the time, v1 UUIDs from the same machine can be chronologically sorted.
The downside: the MAC address reveals the generating machine, which is a privacy concern. Some implementations substitute a random node ID to avoid this.
Choosing UUID vs auto-increment for primary keys
Auto-increment integers are fine for tables with a single primary database. UUIDs are better when:
- Merging data from multiple sources — two databases generating ID 1, 2, 3 will collide. UUIDs never do.
- Client-side ID generation — the client can create the ID before the server acknowledges the write, enabling optimistic UI updates.
- Hiding sequence information — auto-increment IDs leak how many rows exist, making enumeration attacks trivial.
The downside of UUID primary keys is storage and index size. A UUID stored as varchar(36) takes 36 bytes; a bigint takes 8. For read-heavy workloads on large tables, consider storing as binary(16) or using UUID v7 (time-ordered, available in newer databases) which has better index locality.
Formatting conventions
Some systems expect uppercase (550E8400-E29B-41D4-A716-446655440000), some lowercase. Some strip hyphens for compact 32-character storage (550e8400e29b41d4a716446655440000). The generator here gives you both options.
For PostgreSQL use the uuid type. For MySQL use binary(16) and convert with UUID_TO_BIN() / BIN_TO_UUID(). For MongoDB, BSON UUIDs are stored natively.