Wow... That is some nitpicking... The major issue these UUIDs solve for me is the fact that using a random UUID as a primary key of a relational database leads to horrible performance...

It has never crossed my mind to decode the timestamp from them so I save myself a 12-byte column, neither has it crossed my mind to have them monotonic in a distributed system...

▲

mahboi 5 hours ago | parent | next [-]

Serial PK solves this too, better actually cause it's smaller

▲

phoronixrly 5 hours ago | parent [-]

Why would I ever use a UUID PK if I had the option to use a serial one instead?

▲

mahboi 4 hours ago | parent [-]

People do it, but seems like you get it. Every time I'm on a new team or job, they have UUID PKs in a single DB for no reason.

▲

tyre 3 hours ago | parent [-]

It's because it's opaque. Signing up and seeing a page like `/companies/366` unnecessarily leaks company data. Sometime it's a huge deal, sometimes not; not here to litigate that. But it's trivially avoidable.

	▲	tredre3 3 hours ago \| parent [-]
		The UUIDs discussed here leak the time that the record was created, so one could conceivably extract the growth rate, retention, sequence of event, etc. That's not great either. It's almost always better (in my experience) to use auto increment internally, and assign a random hash (or UUID) to each public-facing record. All your SQL will be faster at the cost of one lookup (trivially cached) to match the requested hash/uuid to PK. Of course this requires discipline across the team and, in that sense, "just always use uuidv4" is easier.

▲

alexchamberlain 5 hours ago | parent | prev [-]

The author is in DevSecOps (i understand the Sec part...) - nitpicking is in the job description.