Connection pooling, read replicas, and Pub/Sub

Speaker notes

• A managed database has a hard connection limit independent of CPU or memory — an autoscaling compute fleet without connection pooling in front of the database can exhaust that limit long before the database itself is under real CPU load. This is exactly the interaction between the earlier autoscaling chapters and this chapter's database sizing that's easy to miss.
• A read replica offloads read-only traffic from the primary but does NOT make analytical queries faster against the same data shape — that's a different problem with a different fix (a different database product like AlloyimageDB), not more or bigger replicas. The two problems look similar because both involve read traffic, but the correct fixes diverge.
• Pub/Sub deliberately sits between compute and storage rather than being a storage product itself — this decoupling means the ingestion workers' code never has to change even if the storage destination evolves from a Cloud SQL sink today to Bigtable at greater scale later.

Deck map