I like UUIDv7s as database IDs since they sort chronologically, are unique, and are efficient to generate. My system chooses the UUIDs; I don't allow externally generated IDs in. If I did, then an attacker could easily force a collision. As such, I only care about how fast I create IDs. This is a common pattern.

If your system does need to worry about UUIDv7s generated by the rest of the universe, you likely also need to worry about maliciously created IDs, software bugs, clocks that reset to unix epoch, etc. I worry about those more than a bonefide collision.

Your app is must be popular to be having an entire universe "amount" of users lol

joke aside all of this is theorical, in practical application its literally impossible to hit it that it doesn't matters if its possible or not since you are not google scale anyway

It's not just your app. It's any other app or data provider that you may now or in the future interact with.

Only if the other side uses your key as theirs, and uses it to store data from many sources. I, personally, don't feel it's hardly worth considering. A primary key under your own control doesn't cost much, and is a better choice.

That's not how namespacing works though, is it?

Getting UUID 'A' from app 'X' is easily distinguishable from UUID 'A' from app 'Y'.

The point of the first U in UUID, universal, is that you don't need to use namespacing.

Universal mean unique that uid wouldn't be used anyone else in any point in history or just universal available in one app????

because you just overreach at this point, if you can develop a better one. be my guest

Obviously, just the part within our light cone.