6.3 Connection Budgets and Spanner Consistency

Connection Pooling and Scaling

Relational databases allocate dedicated memory and process threads for each connected client. Exceeding connection limits results in severe resource starvation or crashed database instances.

Connection Limits & The Serverless Problem

• In PostgreSQL and MySQL, the maximum number of concurrent connections is bounded by instance RAM (ranging from 25 connections on small instances up to 4,000+ connections on large instances).
• The Serverless Concurrency Trap: When serverless compute engines like Cloud Run or Cloud Functions scale out to absorb incoming traffic bursts (e.g., scaling to 200 container instances), each container instance might open a pool of 10 connections. 200 instances * 10 connections = 2,000 connections, instantly exhausting database connection capacity and throwing FATAL: remaining connection slots are reserved for non-replication superuser connections.

Mitigation Strategies

1. Application-Level Pooling (HikariCP / SQLAlchemy): For persistent workloads (Compute Engine, GKE), configure client-side connection pools with small pool sizes (e.g., 5-10 connections per application thread pool) and short idle timeouts.
2. Database Proxy Connection Poolers (pgBouncer): Deploy pgBouncer in transaction pooling mode between application services and PostgreSQL. pgBouncer multiplexes thousands of incoming client connections over a compact pool of dozens of persistent server connections, preventing database connection exhaustion.
3. Serverless Max Instances Throttling: On Cloud Run services, set the --max-instances flag to constrain horizontal instance growth, preventing downstream database connection exhaustion.
4. Cloud SQL Auth Proxy & Connectors: The Cloud SQL Auth Proxy establishes an encrypted TLS tunnel using ephemeral certificates that expire in approximately one hour and are refreshed automatically generated via Google Cloud IAM. It avoids authorized-network allowlists and manual certificate handling. It does not create a VPC network path or pool connections; private-IP access still requires appropriate routing.

## Starting Cloud SQL Auth Proxy locally or as a GKE sidecar
cloud-sql-proxy \
    --port 5432 \
    --private-ip \
    my-project:us-central1:my-postgres-instance

---

Worked Connection Budget and Transaction Failure

Suppose a database permits 300 application/administrative connections. Reserve 60 for operations, other clients and recovery, leaving a nominal 240 for the service. With a pool maximum of eight connections per instance, the simple budget is 240 / 8 = 30 instances. This is an estimate, not a hard invariant: concurrent revisions and replacement instances can temporarily overlap. Set additional headroom and use an actual shared pooler/database limit where exceeding capacity is unacceptable.

Keep the pool alive across requests, acquire connections with bounded timeouts and return them reliably after each operation. Check whether the pool counts idle plus active connections and whether a driver opens additional connections for maintenance. A connector protects each connection; it does not replace these pool settings. A larger client pool can make a slow database less reliable by increasing contention.

If a transaction is aborted before commit, retry the complete transaction according to the engine's documented policy so reads are reevaluated. If the network fails during commit, the outcome can be ambiguous. A stable unique business-operation key lets the caller reconcile the result rather than blindly applying the debit twice. Do not retry a transaction callback that sends an irreversible external payment on every invocation; use an outbox or downstream idempotency mechanism.

Cloud Spanner: Globally Distributed Relational Database

Cloud Spanner is Google's enterprise distributed relational database. It combines the structured query interface, schema enforcement, and ACID transaction guarantees of a relational database with the horizontal elasticity and multi-region availability of a NoSQL database.

Architectural Hallmarks

• Horizontal Scaling within Capacity Limits: Compute (nodes) and storage (distributed Colossus filesystem) are decoupled. Nodes can be added or removed dynamically with zero application downtime, with throughput depending on key distribution, queries, capacity, and configuration.
• Multi-Region Active-Active Availability: Multi-region configurations deliver a 99.999% (five nines) availability SLA under the monthly SLA terms and exclusions; it is not a guaranteed annual application-downtime budget, surviving entire regional outages without human intervention.
• External Consistency (Linearizability): Spanner guarantees that if transaction T2 initiates after transaction T1 commits, T2's commit timestamp is strictly greater than T1's. Strong reads observe a consistent timestamp; explicitly stale reads trade freshness for latency. Not every replica operation has the same latency or freshness mode.

The TrueTime API and Clock Uncertainty

Distributed systems historically struggle with clock skew across independent servers. Cloud Spanner resolves this using Google's proprietary TrueTime API:

• Hardware Synchronization: TrueTime relies on synchronized GPS receivers and atomic clocks installed directly inside Google data centers. Because GPS and atomic clocks have different, independent failure modes, this design prevents drift.
• Bounded Clock Uncertainty: TrueTime represents an interval containing the actual time, rather than an assumed perfectly accurate timestamp.
• Commit Wait: A transaction waits until its commit timestamp is definitely in the past before acknowledging the commit. This supports externally consistent ordering; it is not a fixed seven-millisecond bound or a promise of lock-free read-write transactions.

Official references checked October 18, 2026: Google Cloud 1.