Read only replicas are pretty trivial as well.
I routinely work with 10TB+ PostgreSQL clusters, 10TB+ BigTable clusters and 500TB+ BigQuery projects all in my current day job. I'm in Data Infra btw so this is sort of my bread and butter.
In the past I have worked with 100TB+ Cassandra clusters, 50TB+ MySQL+Vitess and countless other stores like MongoDB, RethinkDB, Voldemort, TokyoCabinet and probably tons I have forgotten.
It's highly unlikely one actually works with and manipulates these volumes of data on a regular basis and doesn't respect SQL stores and the JVM (the literal king of Big Data).
Sharding is usually a matter of actually splitting the masters. There are many techniques for achieving this. If you want the database to do all the work you will probably want to use something like Citus for PostgreSQL or Vitess for MySQL.
You can also build bespoke topologies using PostgreSQL logical or MySQL binlog replication.
Failing that you can do application level sharding if you don't want the database doing anything fancy for you and manage each shard as an independent database cluster.
By the time you actually need to do this you will be able to afford one of these options. :)
In the meantime you will save a ton of CPU, storage and development time vs a "NoSQL" store as databases like PostgreSQL are inherently more efficient for all but the simplest of KV access patterns.
What if I need to do this now? Why would I build a distributed postgres snowflake that takes 10 hours to spin up a new replica, requires that I implement my own sharding, instead of using a datastore that is designed to handle all of these things at scale?
There are some pretty decent NoSQL stores now for simpler access patterns. As long as you stay away from nonsense like MongoDB and stick to real databases like Cassandra/ScyllaDB/BigTable/etc you will do fine.
These stores are a fraction as flexible as PostgreSQL/MySQL but do allow scale-out storage and fast primary key lookups and scans. Good for when the size of your data is well in excess of 1TB+ and you don't need anything complex or consistency.
Yes, Visa may need this. Guess what, 1TB+ of transaction data paying 30 center + 2% PER LINE - you'll be able to afford to do something reliable and scalable.
Folks don't realize, noSQL is not actually that scalable except in very narrow ways. And you can spin up pretty good scale SQL stuff with things look AWS RDS, including backups, replicas, snapshots to go back in time etc (noSQL doesn't support a lot of this).