I mean, I'd say for 90% of enterprise or high traffic workloads, a single big db (1990s style as you call it) works very, very well and has done for a long time. Sharding and using distributed dbs is not often actually necessary.
To take one example this high traffic website (HN) uses one db and serial integer ids as you can see in the urls. A single master db with read-only followers can scale very well even for higher workloads than most businesses ever see. There are a lot of businesses trying to solve this problem (distributed ids) that shouldn't be and will in fact never need it.
As we can see from the article UUIDv4 is not suitable as a pk, certainly not where you want good performance, the performance is significantly worse than v7 or integer pks, and v7 isn't really suitable if you want to hide business data because of the time stamps. So distributed dbs are the best use-case, and those are not often necessary IMO.
To take one example this high traffic website (HN) uses one db and serial integer ids as you can see in the urls. A single master db with read-only followers can scale very well even for higher workloads than most businesses ever see. There are a lot of businesses trying to solve this problem (distributed ids) that shouldn't be and will in fact never need it.
As we can see from the article UUIDv4 is not suitable as a pk, certainly not where you want good performance, the performance is significantly worse than v7 or integer pks, and v7 isn't really suitable if you want to hide business data because of the time stamps. So distributed dbs are the best use-case, and those are not often necessary IMO.