But it's not really accurate:

> This adds some undesirable side effects, however. First, the coordinator becomes the bottleneck.

Apart from being able to use any node as a coordinator (and you can load balance them to avoid having "multiple connection strings), there's a new pattern which effectively allows you to have as many coordinators as you want. They are effectively "data-less" nodes. We have devised and implemented this pattern in StackGres [1].

> Adding a shard with more resources for a noisy tenant, or many small shards for a wide shard space requires substantial manual configuration of not only the database servers themselves, but wiring them up together with Citus.

Adding nodes (infrastructure) is what operators solve. In StackGres, adding new nodes means editing one/two characters from your YAML file: the integer number that represents the number of workers that you have.

Shard rebalancing is fully built-into Citus as a UDF, which you can call (manually or in an automated manner) over Postgres protocol.

> Managing backups is also external to Citus, so operators still need to build the proper infrastructure

Agreed, but it's also solved (see distributed backups in StackGres [2]).

> PgDog is a spiritual successor to PgCat, both of which improve on Citus's architecture substantially.

Unsubstantiated why. I assume it's because of the assumption that a proxy model is superior than Citus. To which I have to say that Citus model is also a proxy model, where the proxy just happens to be Postgres, which unsurprisingly, speaks Postgres protocol. Sure, there are nuances that we could debate in this area and we can say that Citus is not a "pure proxy", but that doesn't lead to concluding that a proxy model is better --it's arguably not.

[1]: https://stackgres.io/doc/latest/administration/sharded-clust...

[2]: https://stackgres.io/doc/latest/administration/sharded-clust...