The author is in DevSecOps (i understand the Sec part...) - nitpicking is in the job description.
replySerial PK solves this too, better actually cause it's smaller
replyWhy would I ever use a UUID PK if I had the option to use a serial one instead?
replyPeople 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.
replyIt'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.
replyThe 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.
replyIt'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.