When Your Framework Migration Doubles Latency: Fix These 3 Connection-Pool Anti-Patterns First

You just finished the migration. New framework, cleaner code, promises of better performance. Then the latency graph spikes—double what it was before. The framework isn't slow; your connection pool is. This is the story of three anti-patterns that sneak in during migrations and crush your response times. Let's fix them.

Who Should Read This—And What Happens If You Skip It

Teams in the Middle of a Framework Migration

If you're three weeks into a migration from Express to Fastify—or Django to FastAPI—and your p99 latency just doubled, I'm betting you haven't touched the connection pool yet. Most teams don't. They swap the framework, run a smoke test, see green checks, and ship it. Then, at 3:00 PM on a Wednesday, response times climb from 80ms to 170ms. Not because the new framework is slower. Because your database pool is still tuned for the old one.

The framework itself? It's probably faster. Fastify claims 2x throughput over Express in benchmarks, and FastAPI blows Django out of the water for pure request handling. That speed, however, changes how connections are acquired and released. A faster framework consumes and returns connections at a different cadence. If your pool settings—max, min, acquireTimeout, idleTimeout—were tuned for the old middleware stack, you're now fighting a mismatch. I've seen a team blame Fastify for weeks, only to find their pg-pool was set to max: 10 while their old Express app never needed more than 8. The new framework's concurrency model exhausted those ten connections in under two seconds. Latency doubled. Framework overhead wasn't the culprit—pool starvation was.

'We swapped the framework, and suddenly every endpoint felt sluggish. Turned out the pool was the bottleneck the whole time.'

— Lead backend engineer, mid-migration post-mortem

Developers Who Blame the New Framework for Latency

It's tempting to point fingers at the shiny new thing. I've done it. You deploy the migration branch, hit a few endpoints, and response times are worse. So you assume the new framework's event loop is glitchy, or its ORM integration is half-baked. That sounds fine until you actually profile the pool. The catch is this: a framework change often alters connection behavior silently. Fastify with pg might use a different default pool size than Express did. FastAPI's async handlers can hold connections open longer than Django's synchronous views ever did. The result? Bottleneck appears to be the framework, but the seam blows out inside the pool library.

One team I worked with saw latency jump by 140% after moving to a newer async framework. They spent a sprint rewriting route handlers, adding caching layers, even switching databases. Nothing worked. The fix? They reduced pool.min from 20 to 5 and increased pool.idleTimeoutMillis from 10 seconds to 30. That's it. The old app had been over-provisioning connections because it was slower at acquiring them. The new framework grabbed connections so fast that the pool was constantly cycling idle connections in and out—overhead nobody accounted for. Wrong order. Not yet. That hurts.

Operations Engineers Tuning Connection Pools Blindly

Ops engineers love defaults. I get it—there are a thousand knobs in a migration, and pool settings seem boring. So you leave max_connections at 25 because that's what the old PostgreSQL config used. Then you wonder why the new app returns 503 errors at half the previous traffic. The reality is brutal: your database isn't the bottleneck—your pool's queueTimeout is. Most pools queue requests when all connections are busy. If your framework now processes requests faster than the pool can recycle connections, that queue grows. Growth means latency. Exponential latency, sometimes.

What usually breaks first is the acquireTimeout. A migration I consulted on had it set to 5000ms. The old framework rarely hit that ceiling. The new one? It hit it every 30 seconds at peak traffic. Connections were timing out in the queue, then the app retried, which made the backlog worse. Fixing it required dropping acquireTimeout to 2000ms and adding a circuit breaker on the pool. That's the trade-off: too tight, and you reject requests prematurely; too loose, and you mask a dying pool until latency skyrockets. Ops engineers need to monitor pool queue depth, not just CPU or memory—because a pool can be fully utilized while the database sits at 15% load, and that's where your doubled latency lives.

Prerequisites: What to Have Ready Before You Touch Pool Settings

Baseline latency and throughput metrics from before migration

Most teams skip this step—I have seen it cost them an entire sprint. Without a pre-migration snapshot of your average p50, p95, and p99 latency under normal load, you're tuning connection pools blind. You need numbers that capture real traffic: not synthetic benchmarks run at 3 AM. Grab one full business cycle of metrics: request latency, throughput per second, and connection utilization over that window. The trick is to correlate those numbers with the database's response time. If your app's p95 was 40ms before migration and it jumps to 120ms after, the pool settings are the first suspect—but only because you have the baseline to prove it. Without it, you chase ghosts.

Database or backend service specs and max connections

Your pool size can't exceed what the downstream service can stomach. That sounds obvious—yet I have debugged migrations where the new framework's default pool was 30 connections against a PostgreSQL instance capped at 20. The seam blows out: queued requests pile up, timeouts cascade, latency spikes hard. Pull the max connections limit from the database config (often max_connections in Postgres or @@MAX_CONNECTIONS in SQL Server). Then factor in other consumers sharing that resource. A single microservice hogging the entire pool starves everything else. The ratio to aim for: pool_size = (max_connections / number_of_consumers) * 0.8. That buffer of 20% absorbs bursts without drowning the database. Ignore this and you're tuning a valve that's already maxed open.

“We doubled our app instances but forgot the database connection limit. The pool hit the ceiling, and latency went from 30ms to 4 seconds in twelve minutes.”

— Site reliability engineer, post-mortem on a Node-to-Go migration

Reality check: name the frameworks owner or stop.

Traffic profile: peak concurrency, query duration, idle periods

The pool that works at 2 PM fails at 2 AM—if your traffic profile has wild swings. You need three numbers: concurrent active requests during peak, average query execution time, and the percentage of idle connections in off-hours. Here's the concrete heuristic: if queries take 200ms and you see 500 concurrent requests, a pool of 50 connections creates a queue depth of 10 per connection. That queue amplifies latency linearly. But if your queries drop to 20ms at night, the same pool over-allocates resources—idle connections hold locks or memory for nothing. Trade-off alert: a smaller pool cuts idle waste but risks queue buildup during spikes. The fix is dynamic sizing—most modern frameworks support min/max pool ranges. Set the floor to handle idle periods, the ceiling to cap at the database limit minus 10% headroom. Or use connection pooling middleware that measures response time per connection and adjusts the count per node. That said, half the teams who migrate ignore this entirely. They set one value and walk away. Then latency doubles under load and they blame the framework—when the real culprit is a traffic profile they never mapped.

Core Workflow: Three Anti-Patterns and How to Fix Them Step by Step

Oversized pools: when more connections mean slower responses

Most teams I've consulted start with a simple mental model: more connections equals more throughput. Wrong order. What actually happens—especially under a framework migration where your ORM behaves differently—is connection contention kills your tail latencies. We fixed a Node.js-to-Kotlin migration where the team set maxTotal: 200 on a Tomcat pool that had never needed more than 30. Queries that took 12ms suddenly spiked to 400ms at the 95th percentile. The pool was so large that the database spent more time context-switching between connections than executing queries. The fix: drop maxTotal to 50, set maxIdle to 25, and validate that your middleware (HikariCP, DBCP2, or whatever your new framework uses) actually respects those limits—some drivers silently expand pools. The trade-off is you'll see a brief queue forming during traffic bursts, but that's fine; you'd rather queue for 20ms than let 150 idle connections choke your DB buffers all day.

Idle timeout mismatch: too short causes thrash, too long wastes resources

Here's the fight nobody expects during a migration: your old framework's pool closed idle connections after 30 seconds, but your shiny new Spring Boot app defaults to 10 minutes. That sounds fine until you realize your load balancer health-check interval is 15 seconds. Result? Connections pile up, never drain, and your database's max_connections hits the ceiling during a routine deploy. The opposite side hurts worse—I've seen a team set idleTimeout to 2000ms because they panic-read a tweet. Threads thrash: open, close, open, close, each handshake taking 8–15ms. That's a 40% latency penalty on every request that doesn't reuse a connection. The pragmatic range for most web services is 30000ms (30 seconds) to 120000ms (2 minutes). Match it to your slowest query's typical duration plus a safety margin. The catch is you must also set connectionTimeout to something shorter than your read-timeout; otherwise, dying connections will hold your app hostage for 30 seconds before they're evicted.

Connection leaks: the silent killer that grows pool usage over time

One line of code. That's all it took. A developer forgot to .close() after a select count(*) in a health-check endpoint. Under the old monolith, the container's connection-pool wrapper caught the leak after 5 minutes. Under the new microservice, with Hikari's default leakDetectionThreshold of 0 (disabled), the pool grew to 150 connections at 9:17 AM, peaked at 480 by 11 AM, and the database fell over at 11:23. The fix isn't just enabling leak detection—set it to 30000ms and log a stack trace. But don't stop there: instrument your pool with Micrometer or Dropwizard Metrics. Watch the active count during a quiet hour. It should hover near zero. If it climbs, you've got a leak.

‘We lost $12k in revenue because one prepared statement wasn't closed after an exception. The pool grew silently for three hours before anyone noticed.’

— Chat from a fintech SRE, after they traced their latency spike to a single finally block

The remedy: use try-with-resources on every Connection, Statement, and ResultSet. Run a local soak test with 10,000 requests and assert the pool's active count returns to baseline. That's not optional—it's the difference between a stable migration and a 2 AM page.

Tools and Environment: What You'll Need to Diagnose and Monitor

Connection pool metrics: Prometheus, HikariCP, pgBouncer stats

You can't fix what you can't see — and pool health is surprisingly invisible until the seam blows out. I've watched teams stare at CPU graphs for hours before noticing that their HikariCP `pool.TotalConnections` flatlined at 100 while active connections hovered at 2. That's the classic phantom: connections are leased but never released, and no dashboard screams at you. Export the HikariCP metrics via Micrometer into Prometheus: track `hikaricp_connections_active`, `hikaricp_connections_idle`, `hikaricp_connections_pending`. The pending count is your canary — if it climbs above zero for more than 200ms, your pool is undersized or your queries leak. For pgBouncer, pull `SHOW POOLS` every ten seconds. Look at `cl_active` versus `cl_waiting`. The moment `cl_waiting` hits double digits, your session pool has become a bottleneck. You need 15–30 days of baseline data before you touch a single `maxPoolSize` value — otherwise you're tuning to the current incident, not the steady state.

One painful lesson: Prometheus scrape intervals default to 15 seconds. That hides sub-second connection bursts. We fixed this by dropping to 5-second scrapes during load tests — and suddenly saw the 300ms spikes where connections were queued for 80ms then acquired. The default hid the whole story.

'Most migration latency problems live in the 50–200ms range — your 15-second scrape interval literally can't see them.'

— exhausted SRE, postmortem notes

Load testing tools: wrk, k6, or your own traffic replay

Production traffic is the only honest mirror, but it's also the one you can't afford to break. So you fake it — carefully. Wrk is brutally simple: one binary, one Lua script, and it'll saturate your pool in seconds. The metric that matters isn't throughput — it's the connection-acquisition latency distribution. Add `--latency` to your wrk command and watch the tail. If the 99th percentile acquisition time exceeds 10ms under half your expected load, your pool has a structural problem, not a sizing one. K6 gives you more nuance: you can script login flows that mimic your worst-case migrations, then inspect `http_req_waiting` (time spent queued for a connection) against `vus` (virtual users). The ratio should stay below 0.1 — each millisecond waiting for a pool slot is a millisecond your framework migration steals from the user.

The catch is that synthetic load never reproduces your real database query mix. So we often replay production traffic from a 24-hour window using GoReplay or tcpreplay against a staging environment that mirrors your migrated stack. You need the exact same pool size and connection string you plan to deploy. Most teams skip this: they test with 50 connections against a pool of 200 and declare victory. Deploy to production with the same pool at 50 — and watch latency double as users queue. That's not a migration failure; that's a testing failure.

Database-side monitoring: pg_stat_activity, SHOW POOL, wait events

Your pool's perspective is only half the story. The database sees what your pool ignores — like queries that hold connections for 30 seconds because an index got lost during the migration. Run `pg_stat_activity` every second during your load test and filter for `state = 'active'` and `wait_event_type = 'Lock'`. If you see more than five connections waiting on a lock, your pool is spinning its wheels: connections are alive, doing nothing, while new requests pile up. That's the second anti-pattern — idle-in-transaction queries holding connections hostage. Check `pg_stat_activity` for `state = 'idle in transaction'`; if that count exceeds 10% of your pool, your ORM or framework is failing to close transactions after reads.

PgBouncer's `SHOW POOL` exposes the raw pressure: `cl_active` (hard at work), `cl_waiting` (queue), `sv_active` (database-side connections). The ratio of `cl_waiting` to `cl_active` is your pool pressure index — above 0.1 means your application is requesting connections faster than the database can service them. Not your pool size — your query performance. Wait events on the database side (pg_stat_activity's `wait_event` column) tell you exactly where the bottleneck lives: `IO:DataFileRead` means storage is slow; `Client:ClientRead` means the app isn't pulling results fast enough; `Lock:transactionid` means contention. We fixed a 400ms latency spike by switching from `pool_mode=transaction` to `pool_mode=session` for one specific batch process — and the wait event data proved it wasn't the pool, it was transaction reuse patterns. Your monitoring must answer which component is lying about the latency source — because the pool metrics will always blame the database, and the database will always blame the pool. Actually it's often your query patterns. But you won't know without the raw event data.

Odd bit about frameworks: the dull step fails first.

Variations: When Your Constraints Change the Tuning Rules

Multitenant databases: shared vs dedicated pools

The neat rules you worked out for a single-service pool crumble the moment one database serves ten customers. I have seen teams apply a one-size-fits-all connection limit—say, fifty—and watch tenant A’s batch job starve tenant B’s real-time checkout. The fix sounds obvious: give each tenant its own pool. But pools cost memory, and memory costs real money in cloud-native deployments. The trade-off lands here: shared pools smooth out bursty traffic across tenants but risk noisy-neighbor collapse; dedicated pools isolate failures yet waste idle connections when half your tenants sleep at night. Most teams skip this—they allocate a global max and wait for the PagerDuty alert. Wrong order. You need to decide upfront whether your latency SLO applies per tenant or across the whole fleet. If per-tenant, carve out individual pool sizes with a hard cap per pool and a smaller global ceiling that prevents total exhaustion. If aggregate-only, accept that one tenant’s spike will pull the others down. The catch is that neither choice is permanent—run a tenant traffic audit every quarter. We fixed one migration by adding a maxTotal guard that was 20% lower than the sum of per-tenant maxes; the seam never blew out again.

Serverless and ephemeral compute: pool lifetime and warm-up

Your pool tuning guide from 2019 is useless here. Serverless functions—Lambda, Cloud Run, whatever—spin up and die within minutes. A warm pool of ten connections? Gone when the container freezes. The instinct is to shrink pool sizes aggressively, maybe minIdle: 0, maxSize: 2. That sounds fine until a cold start hits and your function must open a new connection—five hundred milliseconds of SSL handshake plus auth while your user stares at a spinner. What usually breaks first is the pool eviction policy. Default idle-timeout values (ten minutes in many JDBC pools) mean nothing when your runtime lives six minutes. Set eviction intervals to 60 seconds or less. Better yet, skip connection pooling entirely in truly ephemeral contexts and use a lightweight multiplexer like PgBouncer in transaction mode—it keeps a persistent backend pool alive while your Lambda borrows a connection for one query and returns it before the next invocation. The rhetorical question you have to ask: "Is this function handling one query per request, or a series of dependent queries?" If it's a single lookup, don't pool; just connect and close. If it's three sequential queries inside a handler, keep a tiny pool (max 3) and validate the connection before each use. That validation step—a fast SELECT 1—adds 2 ms but saves you a 400 ms retry when the pool returns a stale socket.

High-latency networks: need for larger pools or multiplexing

The standard calculation—poolSize = (requests_per_second * average_query_time)—assumes local latency. Move your database to a different region (or, God forbid, across an ocean) and that formula breaks. I once consulted on a migration where the team kept pool sizes at 30 after moving from us-east-1 to eu-west-1. Network round-trip jumped from 2 ms to 85 ms. Suddenly, each connection held the pool for 45 ms longer, queuing built, and p95 latency tripled. The obvious fix—double the pool—works until your database CPU hits 90%. Then you need multiplexing. PgBouncer in transaction mode (again) lets you share ten backend connections across fifty front-end clients; each application thread borrows the connection only for the duration of a transaction, not the whole HTTP request. That hurts less than it sounds—transaction-mode is safe if you avoid session-level state (temp tables, SET statements). The pitfall: multiplexing works poorly with long-running queries or batch inserts that hold transactions open for seconds. Those lock rows and block other borrowers. You need a query timeout—30 seconds, tops—and a circuit breaker that drops a stuck connection before it takes down the pool. Honest opinion: in high-latency scenarios, larger pools are a bandage, not a cure. Fix the network first—move the database closer, use read replicas, or co-locate your compute. If you can't, accept that multiplexing is your default, not your fallback.

“We doubled the pool, latency dropped for two hours, then the database CPU alarm fired. The real fix was moving the application stack into the same availability zone.”

— Platform engineer, post-migration retrospective

Pitfalls: What to Check When Pool Tuning Doesn't Fix Latency

Connection pool vs. thread pool confusion

You tuned the pool size, waited for the deployment to settle, yet latency still spiked. The first thing I check in these cases isn't the database—it's the application server. Most teams forget that their connection pool competes directly with the thread pool. They're two separate resources, but they share the same hungry CPU. If you doubled your connection pool from 10 to 50 but left the thread pool at 20, you've just created a parking lot: 30 idle connections waiting for a thread that never comes. That hurts.

The fix feels backward—reduce the connection pool. Seriously. I have seen services where cutting connections from 80 to 12 actually dropped p99 latency by 40%. Why? Because each thread could grab a connection instantly instead of waiting for other threads to finish I/O. The trade-off is subtle: you'll see more getConnection() timeouts in logs, but that's fine. Timeouts are faster than queued threads. Monitor thread-pool utilization side-by-side with connection-pool waits; if one is saturated while the other idles, you've found the real bottleneck.

DNS resolution delays in pool creation

Another silent killer—DNS lookups during pool initialization. When your migration swaps the database endpoint, the pool manager might resolve the hostname once and cache it. But what if your DNS has a TTL of 30 seconds and the pool refreshes every 5 minutes? You'll see intermittent 300ms latency spikes that look like database slowness but are actually DNS timeouts. Most teams skip this: they blame the new framework or the migrated queries.

You can test this easily—run dig your-db-host.example.com during a latency event. If response times wobble between 2ms and 250ms, your pool is suffering DNS thundering herd. The fix: pin the IP address in your application config or use a connection string that bypasses DNS entirely—but that's brittle. A better approach: set a local resolver cache with forced 60-second entries. We fixed this once by adding a warmup step that resolves the hostname before the pool starts. Latency dropped immediately.

Database-side limits throttling your pool size

You can tune your pool all day, but if the database has a max_connections of 100 and your pool hits 101, one connection gets dropped—and that drop triggers a retry storm. The catch is that many managed databases (RDS, Cloud SQL) hide these limits. You'll see "too many connections" errors only under load, not during quiet testing. The pitfall: you expand the pool, latency stays flat, every third request times out.

'We increased the pool from 30 to 60 and latency doubled—turns out the database was silently killing every other connection.'

— ops lead at a fintech migration, reflecting on a two-day outage

Check SHOW VARIABLES LIKE 'max_connections' on your target database. Then subtract 5–10% for admin connections and monitoring tools. That's your real ceiling. Also look at innodb_buffer_pool_size—if it's too small, your database will stall on page flushes even with perfect pool settings. The fix: either reduce your pool below the hard limit or increase the database tier. Honest advice—don't tweak database limits without your DBA's signoff; one wrong setting can cascade into a full restart.

Reality check: name the frameworks owner or stop.

FAQ and Checklist: Quick Wins to Verify Before You Panic

How fast should pool acquisition be?

Sub‑millisecond, ideally. If your application waits 5–15 ms just to grab a connection from the pool, you have contention—not a network issue. I once watched a team chase a 40 ms latency regression for two weeks; the culprit was a pool with `maxTotal=4` behind a service that needed 12 concurrent workers. The queue time alone swallowed the budget. A quick sanity check: time `connection-pool.getConnection()` in your startup path. Anything above 2 ms should raise your eyebrows. The catch is that a single slow acquisition often masks a deeper imbalance—too few connections, or a blocking checkout that forces threads to wait while others finish.

What's the right pool size formula?

Stop hunting for a magic number. The formula that works in production is rougher than most guides admit: pool size = (peak concurrent requests × average query duration in seconds) ÷ target response time in seconds. That sounds clean until you factor in connection overhead, database CPU, and the fact that your queries are rarely uniform. A safer heuristic? Start with `2 * number_of_cores` for read‑heavy workloads, then double it if you see queue depth growing. But—here is the pitfall—adding more connections than your database can handle actually increases latency. I have seen a 32‑core database drown under 200 connections because each one held a lock longer than expected. The real trick is to monitor `active_connections` vs `idle_connections`. When idle count stays high while active threads wait, you have a checkout‑time anti‑pattern, not a size problem.

“We doubled the pool size and latency got worse. Turns out the database was context‑switching itself into a coma.”

— senior backend engineer after a failed migration, private Slack post

Checklist: 7 things to verify after any pool config change

You changed one number. Now test these before you panic:

• Checkout timeout – did you set it below your SLA? A 30 s default hides failures.
• Connection leak – run `SHOW PROCESSLIST` before and after a load test; count stuck sleeping connections.
• Validation query – `SELECT 1` is fine, but if your driver runs it on every checkout, you just added 1–3 ms per call. Use `testOnBorrow=false` and `testWhileIdle=true` if your driver supports it.
• Max‑idle vs max‑total – setting `maxIdle` lower than `maxTotal` forces pool churn. On cloud databases, that burns 50–100 ms per reconnect.
• Eviction interval – too aggressive (every 5 s) and you evict connections that are still valid, causing reconnects under load.
• Pre‑pared statement cache – does your pool reuse statements across connections? If not, each new connection re‑parses, spiking CPU.
• Load‑balancer alignment – if your read replicas sit behind a proxy, are pools pinned to specific endpoints? Stale routing can double latency while the pool thinks it's healthy.

Most teams skip item 6. That hurts more than you'd think. We fixed a 60 ms regression once by simply enabling statement caching across the pool—no size change, no timeout tweak. The order matters: validate checkout latency first (sub‑ms), then check for leaks, then adjust size. Wrong order and you'll tune the wrong variable, chasing ghosts while your users feel every millisecond.

Next Steps: What to Do After You Stabilize Latency

Automate pool metric alerting before you forget

The moment latency stabilizes, your brain moves on. I've watched teams celebrate a green dashboard then walk straight into a regression three weeks later because nobody set a single alert. That hurts. Pick three metrics right now: connection wait time (anything above 5ms at P99 should page), pool exhaustion rate (if your pool maxes out even once per hour during peak), and active vs. idle ratio — a pool running 95% active with zero idle is begging to fail when traffic spikes. Wire these into PagerDuty or your ops channel before the end of the day. Cheap insurance against amnesia.

The catch: thresholds that worked last month might break next month. Re-evaluate them during your next load test, not during a post-mortem at 2 AM. Most teams skip this step because they assume "stable" means "finished." It doesn't. Stability is a snapshot, not a destination.

Plan for pool capacity as your traffic curve bends

Your current pool size handles today's load. What happens when your marketing team runs a campaign that doubles concurrent users overnight? I saw a fintech startup's migration fail exactly this way — they tuned pools to a flat baseline, ignored growth projections, and the site fell over during a Black Friday flash sale. The fix wasn't complex: model your pool size against peak traffic forecasts (not averages) and build in a 30% safety margin. A rule of thumb from production chaos: a pool that runs at 70% utilization under normal load leaves room for spikes without forcing queries to queue. Tight pools save memory, loose pools save your night — pick the latter until you have hard data proving you can tighten.

Don't forget that your database's connection limit is a hard ceiling. If your pool maxes at 200 and the DB allows 250, you have zero headroom for administrative queries or background jobs. One migration team I worked with forgot this — their monitoring stack connected via a separate pool that silently tipped the DB over its limit every 90 minutes. That took four days to catch.

Review other migration anti-patterns hiding in plain sight

Connection pools are rarely the only problem. Once latency is under control, look for serialized queries running inside tight loops — that's a classic framework migration trap where the new ORM generates N+1 queries but the old code structure hides them behind a single method call. Profile your endpoints under load; if you see 200 individual queries for a page that previously ran 12, you've got a serialization anti-pattern dressing up as a pool issue. Another frequent offender: connection leak from unclosed transactions. Your old framework probably closed connections implicitly; the new one doesn't. One stale transaction can hold a connection hostage for minutes, starving the entire pool.

'We fixed the pool settings but latency still crept up every Thursday. Turned out a cron job was holding long-running transactions that blocked pool reclamation.'

— production engineer, mid-stage fintech platform

The hard truth: pool tuning covers symptoms, not root causes. Audit your database communication patterns with the same rigor you applied to connection settings. Rewrite serialized query chains into batched operations. Add explicit transaction timeouts — 30 seconds max, less for read-only work. These aren't glamorous fixes, but they're the ones that keep your migration story from having a second act.