That's absolutely true. However, most systems that think they need scale-out are either worrying about a problem they don't have yet, suffering performance problems due to poor database design, or have not fully explored logical (dynamic or hash-based) sharding as a solution to their problems.

A huge proportion of modern software businesses can run on single-writer RDBMS instances, properly engineered, at a fraction of the operational and implementation cost of a scale-out solution. That applies to hosted and self-managed solutions equally, in my experience.

Sure, but scale isn't everything. Operations are far more important, especially when you're a small team.

Modern distributed databases scale better but also have better replication, high-availability with automatic failover and no downtime, easier upgrades, easier backups, and generally less maintenance. Removing the single-point of failure with efficient distribution while being able to run easily on docker/kubernetes makes a big difference over a single monolithic database server.

The desire is generally for high availability now and ability to scale out in the future; while a single write db is generally more than enough performance wise, it doesn't give you high availability which is the main desire.

CitusDB for sharding & replication. Patroni & Stolon for automated replication. Not native solutions, but are an answer.

CitusDB has a ton of limitations on your schema/table structure right now. Over time it has gotten better, so hopefully in the future it will be a true drop-in scale out solution. Specifically some types of relationships + indexes are not supported.

True, but as you said, the compatibility is quickly increasing. They actually did a great job and there is fairly little that is not compatible, usually on very advanced side (which is exactly what we would love to have), but the team is especially good at what they are doing and believe they will get there sooner than later.

Oh yeah totally; it's a slow march forward. MySQL Galera took some time before it was ready for serious use, but the fact that it's semi-usable is awesome.

Citus only does sharding, not replication. Either way, this is a fundamental design limitation with traditional single-master relational systems.

Yea, that's just normal Postgres replication, nothing to do with Citus.

Citus is doing sharding and replication: Citus will shard your data and place every shard on e.g. 3 servers. So one server dying is no problem because the data is replicated 2 times.

Ah I see that now. However that's not by default and it still only applies to "distributed" tables, not all the data in the database. Combined with a single-master, it's nowhere near the replica functionality provided by natively distributed storage systems.

Do they have ACID transactions around writing to all 3 servers? Doesn't that cause bad performance?

You might also end up with a LOT of servers unless you starting sharing servers for different shards (but still with different sets of 3 servers for every shard).

what about PostgresXL. it is a release v behind Postgres. But it has ACID and cluster. I do not have personal experience with it, but would be interested to hear what folks say.

Overall, I agree -- PG with JsonB is extraordinary powerful system, covering document oriented and typical row-oriented use cases.

PGs ecosystem with external foreign interfaces, and in memory streaming solutions (like PipelineDB) - must be an envy of any other db ecosystem.

Valid point, for 99% of startups scaling on one machine (todays SSD based multi core, GB memory hardware is very powerful) with read slaves and failover (Patroni) works just fine. Many I meet as a consultant though want to scale out when they have 100 customers.