Single-Shard Topology vs. Aggressive Connection Pool Tuning for Low-Traffic Costs

When deploying Vitess for low-traffic workloads, the primary goal is to minimize infrastructure overhead while maintaining the operational benefits of the Vitess ecosystem. Two documented paths exist for cost reduction: simplifying the topology to a single-shard deployment or optimizing vtgate connection pooling to reduce resource consumption on existing nodes.

A single-shard configuration eliminates the complexity and node count associated with sharding, but it limits horizontal scalability. Conversely, tuning the connection pool within vtgate can reduce memory and CPU overhead for idle connections, though the documentation does not provide specific baseline values for low-volume environments.

Given a strict budget constraint for a small-scale application, which approach provides better resource efficiency without compromising stability? Specifically, what are the trade-offs between reducing the shard count versus aggressively lowering the idle connection timeouts and pool sizes in vtgate?