>>> Using UUIDv7 is generally discouraged for security when the primary key is exposed to end users in external-facing applications or APIs.

>> So this basically defeats the entire performance improvement of UUIDv7. Because anything coming from the user will need to look up a UUIDv4, which means every new row needs to create an extra random UUIDv4 which gets inserted into a second B-tree index, which recreates the very performance problem UUIDv7 is supposedly solving.

> This is only really true if leaking the creation time of the record is itself a security concern.

No, as "leaking the creation time" is not a concern when API's return resources having properties representing creation/modification timestamps.

Where exposing predictable identifiers creates a security risk, such as exposing UUIDv7 or serial[0] types used as database primary keys, is it enables attackers to be able to synthesize identifiers which match arbitrary resources much quicker than when random identifiers are employed.

0 - https://www.postgresql.org/docs/current/datatype-numeric.htm...

With proper data permission check, having predictable ID is totally fine. And UUIDv7's random part is large enough so that it's much harder to predict than auto increment id.

If your security relies on attacker don't know your ID (you don't do proper data permission check), your security is flawed.