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.