This is a misunderstanding of the purpose of UUIDv7. The whole point is to keep rows physically close, so you can very quickly extract an entire time range from a number of database shards, with minimal reads and compute. And be able to generate them without a centralized server. That's all there was to it, and something you'd only worry about when serving billions of records every hour.
They are also not supposed to be used as public IDs, just like you wouldn't use auto-incrementing IDs that way.
(I wrote a library for this 13y ago [1], around the time Twitter, Instagram et al started reaching enough scale to think about this kind of optimization)
If they’re not supposed to be public ids, what advantage do they have over serial integers for a central db (the vast majority of the web runs this way).
loading story #50219035
UUIDs are one of the most misunderstood things in general, I think. Their entire point is that you don't need a central db to generate them.
loading story #50218761
Do you then maintain a separate column with a UUID for public ids?