The Short Answer: They're The Same Thing
UUID (Universally Unique Identifier) and GUID (Globally Unique Identifier) refer to identical 128-bit identifiers defined by the same technical standard. The only real difference is branding and ecosystem origin:
- UUID is the terminology used by the open-source world — IETF RFC 4122, Linux, Java, Python, PHP, Ruby, PostgreSQL.
- GUID is the terminology coined and popularized by Microsoft — Windows Registry, COM/ActiveX, C#/.NET, SQL Server, Azure.
The actual mathematical structure, bit length (128 bits), and hexadecimal representation (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) are identical in both.
UUID Versions: Which Should You Use?
| Version | How Generated | Uniqueness Basis | Use When |
|---|---|---|---|
| v1 | Timestamp + MAC address | Time-ordered, but leaks your MAC address (privacy risk) | Rarely — only legacy systems |
| v2 | DCE Security (POSIX UIDs) | Domain-specific | Almost never |
| v3 | MD5 hash of namespace + name | Deterministic — same input always gives same UUID | Generating reproducible IDs from known names |
| v4 | Cryptographically random | 122 bits of cryptographic entropy | ✅ Most use cases — databases, session tokens, object IDs |
| v5 | SHA-1 hash of namespace + name | Deterministic (stronger hash than v3) | Reproducible namespace-based IDs |
| v7 | Unix timestamp + random | Time-ordered and random (best of v1 + v4) | ✅ New databases; excellent index performance |
For the vast majority of developers: use v4 for privacy-sensitive IDs (user accounts, sessions, API keys) and consider v7 for primary keys in high-write databases where insert performance matters.
Why UUID v4 is Better than Auto-Incrementing IDs
- Security: Exposes zero information about your database size or user count. An attacker who guesses user ID 1042 doesn't know if user 1043 exists.
- Distributed systems: Multiple servers or microservices can generate IDs independently with no coordination — no central "next ID" counter required.
- Offline generation: Mobile apps can create IDs before syncing to a server (critical for offline-first architectures).
- Merge-safe: Merging data from multiple databases never risks ID collisions.
The Performance Trade-Off
UUIDs do have one legitimate disadvantage: random UUIDs (v4) cause index fragmentation in B-tree database indexes (like PostgreSQL btree or MySQL InnoDB). Each new random UUID inserts into a random position in the index, causing page splits and performance degradation at very high insert rates.
Solutions:
- Use UUID v7 (time-ordered) — inserts are sequential, almost matching integer performance
- Use ULID (Universally Unique Lexicographically Sortable Identifier) — a newer alternative that is 26-character text, lexicographically sortable, and timestamp-prefixed
- Use a composite primary key: an auto-incrementing integer as the actual B-tree key + a UUID column as the public-facing ID