The Max UUID

What it is#

All 128 bits set. Like Nil, it satisfies neither the version nor the variant rules, so no generator will ever produce it and no strict validator will accept it without an explicit exception. Unlike Nil, it is new: RFC 4122 had no such value, so older libraries and older articles do not mention it.

RFC 9562 § 5.10 · Max UUIDThe Max UUID, added by the current standard

Every spelling of it#

The obvious use: bounding a range#

With time-ordered identifiers, a range scan over a UUID key replaces a scan over a timestamp column. Nil is the lower bound and Max the upper, so "everything in this partition" needs no special case and no synthetic sentinel of your own invention.

-- everything, expressed as a range over the key itself
SELECT * FROM events
WHERE id BETWEEN '00000000-0000-0000-0000-000000000000'
             AND 'ffffffff-ffff-ffff-ffff-ffffffffffff';

-- one millisecond of a v7 stream: pad the tail with zeros and with f

The second idea is the useful one in practice: to select every v7 made during one millisecond, build the lower bound from that millisecond followed by zeros and the upper bound from the same millisecond followed by ones. The Max UUID is that trick taken to its limit.

RFC 9562 § 6.11 · SortingSorting, which is what makes a range over identifiers meaningful

What it is not#

Max is not "invalid" and not an error marker. Using it to mean failure creates the same problem as any in-band signal: the day a real value legitimately equals your sentinel, the meaning collapses. Here that day never comes, since nothing generates Max, but the habit spreads to fields where it does.

Support in the wild#

Libraries that predate RFC 9562 may not export a Max constant, and some validators reject it outright. Writing the literal by hand is safe: it is sixteen ff bytes and cannot drift. Check that your storage layer round-trips it before relying on it as a bound.