Also, the concern needs to be around 'accidental' collisions of the same uuid within the same logical namespace. For example, generating the same UUID as a key

Also, the concern needs to be around 'accidental' collisions of the same uuid within the same logical namespace. For example, generating the same UUID as a key for two rows in the same table. Even with weak non-v4 uuids, this is extremely unlikely with any dataset you are likely to be working with, just because even the worst UUID versions still have a fair amount of entropy, so population sizes have to be absurdly large to get even a tiny probability of a collision. UUID's are not meant to be 'secret' or 'hard to guess', and implementations can not be relied on to take care in generating the right kind of random state to ensure they aren't predictable. From the RFC: https://datatracker.ietf.org/doc/html/rfc4122 https://datatracker.ietf.org/doc/html/rfc4122 Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example. A predictable random number source will exacerbate the situation.