A UUID (Universally Unique Identifier) is a 128-bit label used to uniquely identify information in computer systems. It is represented as 32 hexadecimal digits displayed in five groups separated by hyphens:
The format is 8-4-4-4-12 characters, always 36 characters in total including the four hyphens. UUIDs are also called GUIDs (Globally Unique Identifiers), especially in Microsoft environments — they are the same thing.
| Version | How Generated | Sortable? | Best For |
|---|---|---|---|
| v1 | Timestamp + MAC address | Yes (but exposes MAC address) | Legacy systems |
| v3 | MD5 hash of a name + namespace | No | Deterministic IDs from names |
| v4 | Randomly generated | No | General purpose — most widely used |
| v5 | SHA-1 hash of a name + namespace | No | Deterministic IDs (more secure than v3) |
| v7 | Unix timestamp + random bits | Yes ✓ | Database primary keys (recommended) |
UUID v4 is generated entirely from random or pseudo-random data. 122 bits are random; 6 bits are fixed for version/variant markers. It is the most commonly used version because it requires no coordination between systems, exposes no information about when or where it was generated, and has an effectively zero chance of collision.
Ratified in RFC 9562 (2022), UUID v7 embeds a Unix millisecond timestamp in the most significant 48 bits. This means UUIDs sort chronologically, which is a major database performance advantage — most database B-tree indexes benefit significantly from monotonically increasing keys, avoiding page splits and fragmentation.
If you're choosing a UUID type for new database primary keys, v7 is the current best practice recommendation from PostgreSQL and database performance experts.
UUID v4 has 122 random bits. The total number of possible UUID v4 values is 2¹²² ≈ 5.3 × 10³⁶ (5.3 undecillion).
The probability of a collision when generating n UUIDs follows the birthday problem formula. To reach even a 50% probability of a single collision, you would need to generate approximately 2.7 × 10¹⁸ UUIDs — roughly 2.7 billion billion. At 1 billion UUIDs per second, that would take 85 years.
In practice, UUID v4 collisions are a theoretical concern only. Systems generating UUIDs at any realistic scale are safe to treat them as unique.
Both are valid approaches for database primary keys. The choice depends on your requirements:
The modern consensus: use UUID v7 for new systems where you want the benefits of UUIDs — sortable by time, good index performance, distributed generation, and no information leakage.
In practice, yes. The probability of generating a duplicate UUID v4 is approximately 1 in 5.3 undecillion. To have a 50% chance of a collision, you would need to generate 2.7 × 10¹⁸ UUIDs — an entirely theoretical concern at any realistic generation rate. Systems treat UUID v4 as functionally unique without any practical caveats.
UUID v4 is entirely random with no time component, making it non-sortable. UUID v7 (ratified RFC 9562, 2022) embeds a millisecond-precision Unix timestamp in the first 48 bits, making UUIDs sort chronologically. This makes v7 significantly better for database primary keys where sorted insertion reduces index fragmentation and improves query performance.
It depends on your architecture. Auto-increment integers are smaller, faster to index, and simpler. UUIDs work better for distributed systems (multiple servers generating IDs independently), when merging data from multiple databases, or when you don't want to expose record counts through predictable sequential IDs. For new systems, UUID v7 gives you the benefits of UUIDs with much better database performance than v4.
The version digit defines how the UUID was generated. It appears as the first digit of the third group: xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx for v4, xxxxxxxx-xxxx-7xxx-xxxx-xxxxxxxxxxxx for v7. The variant bits in the fourth group identify it as a standard RFC 4122/9562 UUID rather than older proprietary formats.