In the early days of databases, we used auto-incrementing integers for IDs (1, 2, 3...). This was simple, but it had massive problems:
- Security: If my user ID is 100, I can guess that user 101 exists.
- Merging: You cannot merge two databases if they both have a user ID #5.
- Distributed Systems: A server in Tokyo cannot generate an ID without checking with the server in New York to avoid duplicates.
Enter the Universally Unique Identifier (UUID). It is a 128-bit number that is globally unique across space and time. No coordination required.
The UUID Generator creates industry-standard UUIDs instantly.
UUID Versions Explained
Version 1: Time-based + MAC Address
Uses the current timestamp and your computer's MAC address.
- Pro: Sortable by time.
- Con: Privacy risk! It reveals your MAC address and the exact time it was created. Do not use for public IDs.
Version 4: Random (The Gold Standard)
This is what our tool generates. It uses 122 bits of randomness.
- Pro: Completely anonymous.
- Con: Not sortable.
Version 5: SHA-1 Namespace
Generated by hashing a namespace identifier and a name. Useful if you want the same Input to always produce the same UUID.
The Collision Math
Users often ask: "If it's random, what if I generate the same UUID twice?"
The number of possible version 4 UUIDs is 2^122, or roughly 5.3 x 10^36.
To have a 50% chance of a single collision, you would need to generate 1 billion UUIDs per second for 85 years. In practical terms, collisions are impossible.
UUIDs in Databases (Performance)
While UUIDs are great for distributed systems, they are heavy for databases.
- Storage: A UUID stored as text is 36 bytes. An integer is 4 bytes.
- Indexing: Random inserts fragment database indexes (B-Trees), causing performance degradation on massive tables.
Optimization Tip: Store UUIDs as 16-byte binary (BINARY(16) in MySQL, `UUID` type in Postgres) to save space.
Format
A standard UUID looks like this:
123e4567-e89b-12d3-a456-426614174000
It is 32 hexadecimal entries divided into 5 groups (8-4-4-4-12).