What This Video Covers

RFC 9562 overview videos walk through the IETF standard that replaced RFC 4122 in May 2024 — covering why the old standard needed updating, what each new version adds, and what deprecation means in practice.

Skill level: Beginner to intermediate Best for: Developers who have been using UUID v4 and want to understand whether and when to adopt v7

Key Concepts You Will Learn

1. Why RFC 4122 was replaced

RFC 4122 (2005) defined UUID versions 1–5. Its limitations that RFC 9562 addressed:

2. UUID v6 — reordered v1

v6 takes v1’s 60-bit Gregorian timestamp and rearranges the fields so the UUID is lexicographically sortable. It is a bridge for systems already on v1 — same clock precision (100ns), same MAC address node field, but sortable. Not recommended for new systems — use v7 instead. See Time-Based UUID for the field-by-field comparison.

3. UUID v7 — the modern default

v7 uses a clean 48-bit Unix millisecond timestamp, no MAC address, and 74 bits of randomness. It is lexicographically sortable, collision-safe, and privacy-respecting. The recommended choice for database primary keys in 2026. PostgreSQL 18 ships a native uuidv7() function; Python 3.13 adds uuid.uuid7() to the standard library.

4. UUID v8 — application-defined layout

v8 is a blank canvas: only the 4-bit version and 2-bit variant fields are specified. The remaining 122 bits are application-defined. Use it when you need to embed custom metadata — shard IDs, region codes, custom-precision timestamps — while keeping the standard UUID column type. See UUID v8 — Custom Layout.

5. The Max UUID sentinel

Max UUID (ffffffff-ffff-ffff-ffff-ffffffffffff) is all 128 bits set to 1 — the complement of the Nil UUID. Useful as an explicit upper bound in range queries and pagination cursors.

6. Version field position

The version is the single hex digit at position 13 of the UUID string — the first character of the third group (xxxxxxxx-xxxx-Vxxx-xxxx-xxxxxxxxxxxx). Reading this digit tells you which RFC you are dealing with. See UUID Version field and the UUID Decoder tool.

Watch on YouTube

Search for RFC 9562 UUID standard videos on YouTube ↗

Validate a UUID from the Video

Use the UUID Validator to check any UUID from a video example — it shows version, variant, and whether it follows RFC 9562.

Frequently asked questions

Are there videos explaining what RFC 9562 changed in the UUID standard?

Yes. RFC 9562 overview videos cover the three new versions (v6, v7, v8), the Max UUID sentinel, and the deprecation of v1 and v2. The key takeaway is that UUID v7 is now the recommended default for time-ordered identifiers — replacing the privacy-leaking UUID v1. See RFC 9562 video walkthrough and RFC 9562 replaces RFC 4122.

What did RFC 9562 add to the UUID standard?

RFC 9562, published in May 2024, adds UUID v6 (reordered timestamp for sortability), v7 (Unix millisecond timestamp), and v8 (custom layout). It also defines the Max UUID sentinel (all-ones complement of the Nil UUID) and deprecates v1 and v2. The existing format and v3, v4, v5 semantics are unchanged.

Should I use v4 or v7?

Use v7 for database primary keys (time-sortable, index-friendly) and v4 for anything where creation order could leak information, like tokens or share links.

What did RFC 9562 change from RFC 4122?

RFC 9562, published May 2024, added UUID v6 (reordered v1 for sortability), v7 (Unix millisecond timestamp), and v8 (custom application-defined layout). It defined the Max UUID sentinel (ffffffff-ffff-ffff-ffff-ffffffffffff) and explicitly deprecated v1 and v2. The existing format and v3, v4, v5 semantics are unchanged. See RFC 9562 replaces RFC 4122 — full breakdown.

Is UUID v1 deprecated?

Yes. RFC 9562 explicitly deprecates UUID v1 for new work. v1 embeds the host MAC address (a privacy and fingerprinting risk) and its timestamp fields are in a non-lexicographic order. UUID v7 supersedes v1 for all time-ordered use cases. See Time-Based UUID — v1, v6, and v7 compared.