What Is a UUID?
A UUID (Universally Unique Identifier), also called a GUID (Globally Unique Identifier), is a 128-bit number represented as 32 hexadecimal digits arranged in the format:
550e8400-e29b-41d4-a716-446655440000
The format is 8-4-4-4-12 characters separated by hyphens. The 13th character (first digit of the third group) indicates the version.
UUIDs are designed to be generated independently by different systems without coordination and still be unique with extremely high probability. This makes them ideal for distributed systems, where a central ID-assignment authority is a bottleneck.
Version Overview
UUID v1 (timestamp + MAC address). Encodes the current time at 100-nanosecond resolution plus the MAC address of the network interface. Guaranteed unique for a given MAC address (because the timestamp is precise enough that you cannot generate two v1 UUIDs in the same 100ns on the same machine). Problem: exposes the MAC address and can be used to infer when and where a record was created.
UUID v3 (namespace + name, MD5). A deterministic UUID derived by hashing a namespace UUID and a name with MD5. The same namespace + name always produces the same UUID. Useful for generating stable IDs for known resources (URLs, DNS names). Use v5 instead (SHA-1 is better than MD5, and v5 is now preferred).
UUID v4 (random). 122 bits of random data (the remaining 6 bits encode version and variant). This is the most widely used version. No privacy issues, no coordination required, effectively impossible to collide in practice (the probability of collision in 1 billion UUIDs is about 1 in 10^9).
UUID v5 (namespace + name, SHA-1). Same as v3 but using SHA-1 instead of MD5. Preferred over v3 for deterministic UUIDs.
UUID v6 (reordered timestamp). A reordering of v1 fields to make UUIDs monotonically increasing (sortable by creation time). Better database index performance than v4 because sequential UUIDs cause fewer B-tree page splits.
UUID v7 (Unix timestamp + random). The newest version (RFC 9562, 2024). Uses a Unix millisecond timestamp followed by random bits, making UUIDs sortable by creation time. Recommended for new applications that need time-ordered IDs. Much better database performance than v4.
Database Performance Considerations
UUID v4 (fully random) is the most popular but has a known performance problem with relational databases. B-tree indexes are efficient when new entries are inserted in order. Fully random UUIDs cause inserts to scatter across the index, leading to frequent page splits and poor cache utilisation.
UUID v7 solves this by being monotonically increasing. If you are using UUIDs as primary keys in a PostgreSQL or MySQL table with significant write volume, v7 is significantly more efficient than v4.
When to Use UUIDs vs. Auto-Increment IDs
Auto-increment integers are simpler, smaller (8 bytes vs. 16 bytes), and perform better in indexes. Use them for internal tables where you control ID assignment and do not need to merge data from multiple sources.
UUIDs are better when: IDs are generated on the client or in multiple services without coordination; records are merged from multiple databases; IDs should not be sequential and guessable (exposing user count or creation order is a security concern); or records are replicated across systems.
Try It
The UUID Generator on Syntaxly generates v4 UUIDs instantly in the browser, and lets you inspect the structure of any UUID you paste in.