Nil UUID Generator

Legitimate uses for an all-zeros identifier

The nil UUID earns its keep wherever a UUID-typed field needs an explicit "nothing here" value. Tree structures use it as the parent ID of root nodes when the schema forbids NULL foreign keys. Typed languages use it as the zero value: Go's uuid.Nil and C#'s Guid.Empty are both the nil UUID, so an unset struct field is detectable with a single comparison. Test fixtures use it as a stable, obviously-fake placeholder that no generator will ever collide with. RFC 9562 also added its mirror image, the max UUID ffffffff-ffff-ffff-ffff-ffffffffffff, with all 128 bits set to one, useful as the upper bound when range-scanning a UUID-keyed index just as nil serves as the lower bound.

The anti-pattern: storing nil instead of NULL

Trouble starts when nil UUIDs leak into database columns as a lazy stand-in for SQL NULL. A nullable column with NULL says "no value" in a way the database understands: NULL is excluded from equality joins, skipped by most index scans, and handled correctly by IS NULL predicates. A stored nil UUID is the opposite: it is a real value that joins happily against any other accidental nil, so one unset field on each side of a join can fabricate row matches out of nothing.

The rule we follow: if the column can be absent, make it nullable and store NULL. Reserve the nil UUID for in-memory sentinels, wire formats that cannot express null, and schemas where a non-null placeholder is a deliberate, documented choice.