What is a UUID?
A UUID (Universally Unique Identifier) is a 128-bit value designed to be unique across space and time—without needing a central authority. It’s commonly represented as 36 characters (32 hex + 4 hyphens), for example:
550e8400-e29b-41d4-a716-446655440000
- 128 bits = 16 bytes
- Text forms: hyphenated (
8-4-4-4-12), or compact 32-hex - Case-insensitive:
A–Fcan be upper or lower - Nil UUID:
00000000-0000-0000-0000-000000000000(special “all zeros”)
The Official Standard (2025)
The current IETF standard is RFC 9562 (May 2024), which replaces RFC 4122. It clarifies older versions and introduces modern, time-ordered formats to improve performance in databases and logs.
UUID Versions and Definitions at a Glance
| Version | Key Idea | Typical Use | Notes |
|---|---|---|---|
| UUID v1 | Time + node identifier | Legacy systems, log correlation | Can leak timing/host info. |
| UUID v2 | DCE security (POSIX IDs) | Specialized/legacy | Rare outside DCE contexts. |
| UUID v3 | Name-based (MD5) | Stable IDs from a name | Deterministic; MD5 is outdated. Prefer v5. |
| UUID v4 | Random (122 random bits) | General purpose IDs | Simple, widely supported. |
| UUID v5 | Name-based (SHA-1) | Stable IDs from a name | Deterministic; same input → same UUID. |
| UUID v6 | Time-ordered (reordered v1) | Ordered inserts | Superseded in practice by v7. |
| UUID v7 | Time-ordered + randomness | DB keys, logs, event streams | Modern default for ordered UUIDs. |
| UUID v8 | Custom | Interop/experiments | For vendor/format experiments. |
Quick picks:
- Need ordered IDs for better DB indexing? → UUIDv7
- Need deterministic IDs from a stable input (e.g., URL, email)? → UUIDv5
- Need a simple, unpredictable ID and ordering doesn’t matter? → UUIDv4
[ Advertisement • Our Partners ]
Why UUIDv7 is the 2025 “sweet spot”
- Time-ordered: encodes a Unix timestamp (ms precision) in the high bits → great index locality and range scans.
- Still unpredictable: remaining bits are random, so guessing future IDs is impractical.
- Operational wins: smoother B-tree inserts, fewer page splits, faster ingestion at scale.
If you currently usev1for ordering, moving tov7gives similar ordering benefits without leaking hardware identifiers.
Collision Risk (Do You Need to Worry?)
For v4 (122 random bits), collisions are astronomically unlikely. A back-of-the-envelope estimate: you’d need to generate ~1 billion UUIDs per second for ~85 years to hit a ~50% chance of a single collision—far beyond typical workloads. Use a high-quality RNG and you’re done.
Bottom line: for real systems, treat properly generated v4/v7 UUIDs as unique.
Name-Based UUIDs (v3/v5) in Plain Terms
- Combine a namespace (e.g., DNS, URL) with a name (your string) and hash it.
- Deterministic: the same inputs always produce the same UUID.
- Great for idempotency keys, deduplication, cross-service stable references.
- Prefer v5 (SHA-1) over v3 (MD5). (Do not treat these as “passwords” or security tokens.)
Best Practices
- Choose the right version
- v7 for time-order + performance in databases.
- v4 when you just need strong, random IDs.
- v5 for deterministic IDs from names (pick a fixed namespace).
- Storage tips
- Use 16-byte binary columns where possible (e.g.,
BINARY(16)), notCHAR(36), to save space and speed comparisons. - For PostgreSQL, use the
uuidtype; for ordered semantics, storev7.
- Indexing
- Prefer v7 to avoid random insert hotspots and to improve index locality.
- Formatting
- Accept both hyphenated and compact; normalize to one format for logs. - Treat input as case-insensitive hex.
- Security
- UUIDs are identifiers, not secrets. Don’t expose sensitive info via v1 timestamps/node IDs. Don’t use UUIDs as auth tokens.
- Validation
- Enforce:
- 32 hex (compact) or
8-4-4-4-12with hyphens - Correct version nibble (
1–8) - Correct variant bits (
10xxfor RFC-standard)
[ Advertisement • Our Partners ]
FAQ
A UUID is a 128-bit identifier typically shown as 36 characters: 8-4-4-4-12 hex with hyphens (e.g., 550e8400-e29b-41d4-a716-446655440000). It’s case-insensitive and may also appear as 32 hex characters without hyphens.
Default to UUIDv7 for time-ordered, index-friendly IDs in databases. Use UUIDv4 for simple, random IDs when ordering doesn’t matter. Use UUIDv5 when you need deterministic IDs derived from a name.
v4 is purely random (122 random bits), great for simplicity but not naturally sortable. v7 encodes a timestamp in the high bits and randomness in the rest, giving near-chronological sorting with good unpredictability—ideal for write-heavy DBs and logs.
Practically yes in most developer contexts. “GUID” is the Microsoft term; “UUID” is the IETF standard name. Both refer to 128-bit unique identifiers.
Yes with v7 (designed for time-order). v1/v6 also sort by time but have privacy/legacy concerns. v4 is random and not sortable by time.
With a proper RNG, v4/v7 collisions are astronomically unlikely for real-world volumes. Treat them as unique; ensure you’re using a high-quality generator.
Use v5 to derive a stable ID from a namespace (e.g., DNS, URL) and name (input string). Same inputs → same UUID. Useful for idempotency keys, dedup, and cross-service references.
UUIDs are identifiers, not secrets. Don’t rely on them for authentication or authorization. Keep sensitive data out of v1 (which can leak time/host info). Prefer v4/v7 and use real secrets for security.
Prefer 16-byte binary types where available (e.g., PostgreSQL uuid, MySQL BINARY(16)), not CHAR(36). This saves space and improves comparisons and index performance.
v7’s time-ordered high bits improve B-tree locality, reduce page splits, and speed ingestion. It retains randomness to avoid predictability while enabling efficient range scans.
The nil UUID is all zeros: 00000000-0000-0000-0000-000000000000. It represents an “empty” or uninitialized value; don’t use it for real entities.
Check for either 32 hex (compact) or 8-4-4-4-12 hex with hyphens, case-insensitive, correct version nibble (1–8) and variant (8|9|a|b). Reject anything else.
No. Hex is case-insensitive. Normalize to one style (often lowercase) for consistency in logs and UIs.
Avoid it. UUIDs are designed to be opaque. If you need human-readable or strictly monotonic IDs, use separate sequential or ULID/KSUID-style schemes with clear trade-offs.
Yes in most new development. v7 preserves ordering benefits without exposing MAC/time details. For migrations, dual-write or backfill while keeping primary keys stable to avoid mass rekeys.
None semantically. Hyphens aid readability; compact saves bytes in text. Store binary internally and choose a single presentation format externally.
Yes. With v7 (or v4 + additional ordering strategy), databases handle them well. Ensure proper indexing, use binary storage, and benchmark for your workload.
Pick a fixed namespace UUID (DNS/URL/own namespace) and a stable input string. Hashing (SHA-1) produces the same UUID every time. Don’t use v5 for secrets; treat it as a stable identifier only.
[ Advertisement • Our Partners ]
Quick Reference Snippets
Recognize a UUID (case-insensitive, hyphenated):
^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$
Compact (no hyphens):
^[0-9a-fA-F]{32}$
Detect version from the 13th hex nibble (1–8) and variant from the 17th nibble (8|9|a|b).
When to Prefer Sequential IDs Instead
- You need strict monotonic integers (e.g., invoice numbers users see).
- You have tiny tables and want human-readable keys.
- You must embed business meaning in IDs (UUIDs are intentionally opaque).
In all other cases, UUIDv7 is a strong default for 2025.
[ Advertisement • Our Partners ]