Why t3.micro RDS connections break FastAPI backends and how to fix it

Cloud services promise scalability, but buried under polished dashboards is a harsh reality: connection limits in managed databases throttle growth faster than processors or memory. A recent incident on DEV Community’s FastAPI backend exposed this exact bottleneck when a t3.micro RDS instance capped out at 87 simultaneous connections, forcing a hard reset on scaling assumptions.

The invisible ceiling: when connections trump CPU

The backend relied on a single PostgreSQL database shared across API handlers and background workers. Despite running on AWS Fargate with auto-scaling enabled, the system hit a wall not in CPU usage or response times, but in the raw number of open database connections. This constraint is inherent to RDS instance classes like t3.micro, which enforce a strict limit on concurrent connections regardless of compute power.

For teams building on AWS, this means that increasing task counts in ECS or Fargate doesn’t automatically translate to higher throughput. If each container maintains a pool of database connections, multiplying instances can quickly exhaust the database’s connection budget. In this case, the ceiling was reached at just two running tasks—each configured with a pool of 20 connections, including overflow—leaving no room for ad-hoc queries, migrations, or even monitoring tools.

Behind the pool: how a modest config snowballs into collapse

The connection pool configuration in FastAPI using asyncpg and SQLAlchemy looked unassuming at first:

engine = create_async_engine(
    settings.DATABASE_URL,
    connect_args={"ssl": "prefer"},
    pool_pre_ping=True,
    pool_size=8,
    max_overflow=12,  # total 20 connections per process
    pool_recycle=1800,  # 30 minutes
)

But when multiplied across the architecture, the math revealed a silent bomb:

• Two Uvicorn workers per container → 20 connections × 2 = 40 connections per task
• Rolling deployment with old and new tasks running simultaneously → 40 + 40 = 80 connections
• Background worker tasks (e.g., cron jobs) sharing the same pool → additional 7 connections
• Occasional migrations, psql sessions, or health checks → a few more

The sum landed at approximately 87 total connections—exactly the limit set by t3.micro. With no margin, a single spike in traffic or a scheduled job firing at the same time could trigger QueuePool limit reached or the dreaded FATAL: too many connections.

This isn’t a tuning issue. It’s a resource rationing problem. The pool size isn’t just about performance—it’s about survival.

The day it failed: timing, not size, broke the system

On May 27, 2026, the pool was set to 8/12 connections per process. At the top of the hour, four scheduled cron jobs (ama, challenge, marketplace, daily_token_digest) all triggered simultaneously. Each opened a new connection, competing with live API requests for the same eight slots. With no buffer, writes began timing out, and connection attempts failed under pressure.

The error message was clear but misleading:

QueuePool limit of size 3 overflow 5 reached, connection timed out

The immediate diagnosis pointed to the pool being too small. But the deeper issue wasn’t size—it was timing and isolation. The cron jobs were not spread out; they all fired at the same minute mark, creating a coordinated surge that turned independent tasks into a stampede.

The fix wasn’t just increasing the pool to 8/12 (20 total). It was recognizing that background tasks and API handlers were sharing the same scarce resource. Without separation, scaling one meant starving the other.

Fixes that work—and the one that doesn’t

Two mitigation strategies proved critical to preventing silent connection rot:

• pool_pre_ping=True: Before handing a connection to a client, SQLAlchemy sends a lightweight SELECT 1 to verify liveness. This catches stale sockets caused by RDS restarts or NAT timeouts without requiring application-level retries. Without it, long-lived connections could appear healthy until the first real query failed.
• pool_recycle=1800: Forces connections to refresh after 30 minutes. Even with pre-ping, some dead connections can pass the health check. A hard recycle ensures they’re replaced before they cause a cascading failure.

These settings don’t expand capacity—they preserve what’s available. They prevent a slow bleed of broken connections from eroding the pool’s usable size over time.

Meanwhile, RDS Proxy is often recommended as a universal fix. But in this case, it wouldn’t solve the root cause. RDS Proxy manages connection routing and failover, but it doesn’t increase the underlying database’s connection capacity. If the proxy sends 200 concurrent requests to a t3.micro instance limited to 87 connections, the bottleneck shifts—not disappears.

Testing without pooling: the hard truth

During development and CI, teams often use NullPool to avoid pooling altogether. This approach opens and closes a fresh connection for each database query, simulating a stateless environment. It’s slower, but it exposes race conditions that real pooling might mask.

In the testing setup, the configuration forced a clean separation:

engine = create_async_engine(
    TEST_DATABASE_URL,
    poolclass=NullPool
)

This prevents subtle bugs where a connection tied to one async event loop is reused in another, causing RuntimeError: Session is bound to a different loop. While slower for tests, NullPool ensures correctness and avoids false positives in load simulations.

What to do next: beyond the pool

The lesson is clear: never assume compute scales with traffic. Start by auditing your database’s connection limit using SHOW max_connections; in PostgreSQL. Then model your connection usage across all services sharing the same database.

Avoid synchronous bursts in cron jobs. Use random jitter in job scheduling to spread load. Consider splitting background workers into separate processes with their own, smaller pools. And always monitor connection metrics—not just CPU and memory.

RDS Proxy can help manage failover and routing, but it won’t fix a misaligned pool strategy. The real solution lies in understanding that in serverless and containerized environments, the database connection budget is the new bottleneck—and it must be respected.