One angle I haven't seen discussed here: for people running multiple apps against a single Postgres instance (which is extremely common in smaller deployments — Nextcloud, Gitea, wiki, etc. each creating their own database), the connection pooling alone is valuable even without sharding.
Each of those apps tends to open its own connection pool with generous defaults, and you quickly end up with 200+ backend connections on a modest VPS that only has 4GB of RAM. PgBouncer solves this but it is one more thing to configure and maintain separately. Having pooling and query routing in the same proxy is a nice consolidation.
The expanded_explain feature mentioned in the docs is a smart design choice for building trust — being able to see routing decisions before going to production removes a lot of the "is this actually going to the right shard" anxiety. Citus required similar introspection tooling before people were comfortable adopting it.
Each of those apps tends to open its own connection pool with generous defaults, and you quickly end up with 200+ backend connections on a modest VPS that only has 4GB of RAM. PgBouncer solves this but it is one more thing to configure and maintain separately. Having pooling and query routing in the same proxy is a nice consolidation.
The expanded_explain feature mentioned in the docs is a smart design choice for building trust — being able to see routing decisions before going to production removes a lot of the "is this actually going to the right shard" anxiety. Citus required similar introspection tooling before people were comfortable adopting it.