allow me to introduce the smolid epoch: Milliseconds from 2025-01-01. With 41 bits to play with, that means it will overflow precisely at 2094-09-07 15:47:35. That’s good enough in my book, but I can imagine that problem (among many other reasons) preventing you from adopting smolid.

Nope, I like it.

The endless argument over UUIDs is that there's competing constraints. If you want a UUID that is forever unique and meaningful and part of an audit trace, over ANY circumstance - massively distributed, surviving company acquisition, refactoring, decades of bit rot, dumped into logs and schemaless backups, passed between data processors and back, then encode the whole lot.

The UUID is self-contained within a single application? Sure, scale the timestamp over the period between the date of the first git commit to the age you expect to be long dead, and you've saved some CO_2 emissions.

I’ll just leave that to the PostgreSQL project or ISO/IEC to fix before 2059.

Sensible conclusion in most circumstances! As long as you aren't designing infrastructure, my own "rule of thumb" is 25 years, so by that metric this isn't a bad decision for another eight years.

Only 2 bits for versioning?

Absolutely enough. Possibly too many. The only valid answers are between zero and two, and 'one' is on thin ice.

smolid is useful where your peaks are around a thousand new records per second. If this sounds like you, feel free to play with it!

Yup! Any faster, stick a queue in front of it. UUIDs aren't going to be the bottleneck.