--- title: Adding More Servers Made Our API Slower. Here's Why. description: Discussion about "Adding More Servers Made Our API Slower. Here's Why." on daily.dev - join the developer community canonical: https://daily.dev/posts/adding-more-servers-made-our-api-slower-here-s-why--1drdnsxau twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Adding More Servers Made Our API Slower. Here's Why. | daily.dev og:description: Discussion about "Adding More Servers Made Our API Slower. Here's Why." on daily.dev - join the developer community og:url: https://daily.dev/posts/adding-more-servers-made-our-api-slower-here-s-why--1drdnsxau og:image: https://api.daily.dev/og/posts/1DRdNSXau.png og:image:alt: Adding More Servers Made Our API Slower. Here's Why. og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Adding More Servers Made Our API Slower. Here's Why. **[Sina Rezaei](https://daily.dev/sources/sm3o9wzwqzhzlr6lsyoyg)** · [@sinarezaei](https://daily.dev/sinarezaei) · 1 upvotes · 0 comments ## Content You scale an API from 4 instances to 12 because traffic is growing. CPU usage drops, the load balancer has more targets, and everything looks fine at first. Then p95 latency jumps from 180 ms to 1.4 seconds. Requests start timing out, and the database connection pool is constantly exhausted. What happened? Let's say each instance has a PostgreSQL pool configured for 30 connections. With 4 instances, the application can open up to 120 connections. With 12, that number becomes 360. The database didn't get three times faster just because the application did. If PostgreSQL was already close to its useful concurrency limit, those extra connections can mean more memory usage, context switching, lock contention, and transactions competing for the same resources. Throughput can flatten or even fall while latency keeps climbing. The PostgreSQL wiki explains this trade-off in its discussion of database connections. There's another catch: requests don't stop existing just because a client gives up waiting. If the API times out and retries, the original query might still be running while another attempt enters the system. Now you're paying for work that may no longer be useful. I'd investigate the database before adding another batch of instances. Check active queries, lock waits, connection-pool wait time, transaction duration, and whether a recent deployment changed query patterns. Then load-test different pool sizes while measuring completed requests per second and p95/p99 latency, not just CPU. Sometimes the fix is a better query or shorter transaction. Sometimes it's a smaller application pool, a connection pooler such as PgBouncer, or admission control that stops the database from accepting more concurrent work than it can handle efficiently. The interesting part is that scaling the API and scaling the database are coupled decisions. Increasing the first can multiply demand on the second without adding any database capacity. **More servers give you more room to process work. They don't guarantee that the bottleneck can process it any faster.** Have you ever seen horizontal scaling make a production system slower instead of faster? --- [View this post on daily.dev](https://daily.dev/posts/adding-more-servers-made-our-api-slower-here-s-why--1drdnsxau) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"DiscussionForumPosting","mainEntityOfPage":"https://daily.dev/posts/adding-more-servers-made-our-api-slower-here-s-why--1drdnsxau","headline":"Adding More Servers Made Our API Slower. Here's Why.","text":"Discussion about \"Adding More Servers Made Our API Slower. Here's Why.\" on daily.dev - join the developer community","url":"https://daily.dev/posts/adding-more-servers-made-our-api-slower-here-s-why--1drdnsxau","datePublished":"2026-10-24T05:57:43.916Z","dateModified":"2026-10-24T06:00:48.397Z","author":{"@type":"Person","name":"Sina Rezaei","url":"https://daily.dev/sinarezaei","image":"https://lh3.googleusercontent.com/a/ACg8ocLXjJ5mCeyMCQK6CSjPfPxZisLuVwj3KOgnAtXoJoPAAsuvSrxh=s96-c","description":"Project Manager | Digital Strategist | Analytics | Creator | Full-Stack Developer 🗼 🏰 ❾¾ 🦁⃝⃒⃤ ☯","interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"EndorseAction"},"userInteractionCount":320}},"image":"https://media.daily.dev/image/upload/s--5C1jf5ja--/f_auto,pg_1/v1792821464/posts/1DRdNSXau?_a=BAMAMiiw0","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"isPartOf":{"@type":"WebPage","url":"https://daily.dev/sources/sm3o9wzwqzhzlr6lsyoyg","name":"Sina Rezaei"}} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Sina Rezaei","item":"https://daily.dev/sources/sm3o9wzwqzhzlr6lsyoyg"},{"@type":"ListItem","position":3,"name":"Adding More Servers Made Our API Slower. Here's Why."}]} ```