It's wild and hilarious, how often startups and companies go for distributed databases like CockroachDB/TiDB/Yugabyte before they actually need distribution, this trends sucks. 100 million rows is nothing that a well-tuned Postgres or MySQL instance (or even read-replicated setup) can't handle comfortably. Scale when you hit the wall.
Yes, there are multiple steps to consider before jumping to a distributed database and only when you actually hit bottlenecks, like read replication, CQRS, etc. But I guess it's often just about chasing fancy stuff.
HA is important. But Postgres and MySQL both support HA and replication setups without needing to jump straight into a distributed SQL (In this context of using cockroach). We use MySQL Innodb cluster + MySQL router with auto failover on single primary mode.
> If you start having replicas you are already in distributed territory.
But it’s not the same as a distributed database with quorum writes, global consensus, and cross-region latencies. Those systems are built for horizontal write scaling, that come with added complexity and cost, which most apps don’t need.
That depends. You don’t need quorum writes with traditional Postgres or MySQL HA setups. In most cases, writes go to a single primary, and replication to standbys is asynchronous or semi-synchronous, depending on your tolerance for potential data loss.
It’s all about finding the right balance. With modern vertically scalable hardware and fast SSDs, a single-node setup can handle quite a lot of load before hitting real limits with a failover setups.
Thanks, I agree there's a balance. I'm having trouble believing startups don't to be protected from such dataloss. It makes perfect sense (at least to me) for startups to use some standard NoSQL cloud db's like DynamoDB.
If you are a startup you can focus on product and leave the nitty grittys to an abstraction by paying more money.
