Not entirely correct. The distributed database can scale computation horizontally across the nodes in cluster. Single node is better only for the relatively small dataset. If you go higher volumes and velocity, Vertical scaling is still more expensive than Horizontal scaling. If your data is large, with network bandwidth of 1Gbps (or perhaps better) distributed database may choose to replicate it efficiently across the nodes and do scatter-gather (or divide and conquer) query parallelization and also maintain HA. Citus DB is one example of distributed database which does exactly that.

That’s basically what I said...the point is that simple queries on the same keys will never be faster.

There's definitely cases where a distributed database will have higher bandwidth than a single-node database. Since each range is replicated across 3 machines, that means if you have a lot more nodes than 3, the overlap of ranges significantly decreases and you start being able to handle more requests than a single node can.

However, the latency will typically be higher since it always has to talk to at least 3 nodes.

If you consider CRDB's DistSQL which lets you run queries on multiple machines, it might be possible to beat a traditional RDBMS on read latency for large queries.

It would be nice if CRDB could have a mode when 1-3 nodes are active that is similar to since master performance with automatic replication. Then if horizontal scale-out is needed a performance hit could be taken.

I like the automatic replication of CRDB but the vast majority of apps can't afford to take a big performance hit and don't need large horizontal scale-out.

You can run CRDB with only one replica per range. You just lose a lot of reliability if a node goes down.

They also only handle data corruption at the cluster level so there's not really any tools to extract data from a partially corrupted DB on a single node.

I totally agree. So true. Lots of time I ask myself what is the point of compare a single node RDBMS to a distributed database.

Even with MySQL, the replication is still asynchronous from binlog? Is it also the case with postgres?

Yes, postgres has sync and async replication with the ability to even choose a quorum (so that 2 of 3 replicas confirm).

Also has logical replication now, although I wouldnt recommend it because it doesn't support DDL changes yet. Overall it's a solid db choice, but there is still some work involved.

Otherwise I'd recommend SQL Server for a fantastic commercial database that runs cross-platform and has great tooling to make everything easier and some advanced features.

In postgres you can choose if the replication is synchronous or asynchronous. For cascade replication (a slave uses as a master for another slave) the replica is always async.