A team ships a new scraper, buys a pool because the number sounded impressive, and watches success rates collapse in week two. Another team buys a tenth of what it needs, blames the provider for blocks that were really self-inflicted rate limiting, and rewrites perfectly good code. Both failures come from the same gap: nobody sat down and calculated the load.
Proxy capacity planning is not guesswork, and it is not a function of pool size advertised on a pricing page. It is arithmetic built on four measurable inputs: how many requests you actually issue, how long each one takes, how much traffic a single IP can carry against a specific target before it degrades, and how many bytes cross the wire per request. Get those four numbers and pool sizing becomes a spreadsheet exercise. Skip them and you will either overpay or spend your quarter debugging bans that were baked in from day one.
This guide walks through the calculations, the pool-type differences that change them, and the instrumentation you need to keep the plan honest once traffic is live.
Start With the Work, Not With an IP Count
The question "how many proxies do I need?" is unanswerable as stated, because a proxy is not a fixed unit of capacity. One datacenter IP can serve 50,000 requests a day against a tolerant API and get blocked after 40 requests against a hardened e-commerce search endpoint. The IP did not change. The target's tolerance did.
So reframe the question. What you are really sizing is a request budget per IP per target, and then dividing your workload by it. Everything else in this guide exists to make that division accurate.
A useful mental model: your proxy pool is a fleet of delivery vans. You do not ask how many vans you need in the abstract. You ask how many parcels per hour, how far each trip is, how many parcels fit in a van, and how many vans are off the road for repairs. Same structure, different units.
The Four Numbers That Drive Every Capacity Plan
1. Effective request volume, after retries
Start with base volume: pages or API calls per day. Then inflate it for failures, because retries consume capacity exactly like first attempts do.
If your failure rate is 15 percent and you retry until success, effective volume is roughly base divided by (1 minus failure rate). A million pages at a 15 percent failure rate is about 1.18 million actual requests. At a 40 percent failure rate, which is common on aggressively defended targets before you tune, it is 1.67 million. Retry amplification is the single most underestimated line in proxy budgets, and it compounds: worse IP quality raises the failure rate, which raises volume, which raises pressure per IP, which raises the failure rate again.
Plan against effective volume, not the number in your product spec.
2. Concurrency, via Little's Law
Concurrency is not a preference. It is determined by throughput and latency: concurrent connections = requests per second multiplied by average seconds per request.
Take 1.2 million effective requests per day. That averages roughly 14 requests per second. If your average end-to-end request time through a residential exit is 2.5 seconds, you need about 35 simultaneous in-flight requests just to hit the average. But traffic is never flat. If you compress the job into an eight hour window, you are at 42 requests per second and 105 concurrent connections. Add a 3x peak factor for burst scheduling and you are planning for 300.
This matters because concurrency, not IP count, is what most providers actually meter or throttle, and it is what your own connection pooling has to support. A plan that ignores latency will always undersize.
3. Request budget per IP per target
This is the number you cannot look up. You have to measure it with a soak test: point a small number of IPs at the target, ramp request rate slowly, and record where success rate starts to slide, where CAPTCHAs appear, and where the IP stops recovering after a cool-down.
Typical shapes we see in practice: a tolerant public API might accept several hundred requests per hour per IP; a mainstream retail site with commercial bot management might degrade past 40 to 80 requests per hour per residential IP; a search engine results page might tolerate far less, especially with tight query patterns. Treat every number you read online, including these, as a starting hypothesis rather than a constant.
Once you have it, the core formula is simple: distinct IPs needed per hour = effective requests per hour divided by the per-IP hourly budget. For 42,000 requests per hour at a budget of 60, that is 700 distinct IPs active every hour. Over an eight hour run with no reuse inside the window, that is 5,600 IP touches. Whether that requires a pool of 5,600 or a pool of 700 with hourly rest cycles depends on how quickly the target's memory of an IP decays.
4. Bandwidth per request
Bandwidth is where budgets die quietly, because the multiplier between collection methods is enormous.
Raw HTML with a plain HTTP client typically lands between 60 KB and 250 KB per page, and gzip helps a lot. A JSON API response can be under 10 KB. A full headless browser render, pulling images, fonts, CSS and third party scripts, routinely costs 2 MB to 6 MB per page unless you block resources aggressively.
One million pages at 150 KB is about 150 GB. The same million pages through an untuned headless browser at 3 MB is roughly 3 TB. Same job, twenty times the metered spend. Blocking images, media, and analytics tags in Playwright or Puppeteer is usually the highest-leverage cost optimisation available to a scraping team, and it often cuts per-page bytes by 70 percent or more.
A Worked Sizing Example
Suppose you monitor 400,000 product pages daily across 12 retail domains, refreshed once per day, with a headless browser for a quarter of pages and plain HTTP for the rest.
Base volume is 400,000. At an observed 20 percent failure rate, effective volume is 500,000. Spread across a ten hour window, that is 50,000 requests per hour, or about 14 per second. At an average 3 second request time, you need roughly 42 concurrent connections sustained, and you should provision headroom for 120 to absorb bursts and slow tails.
With a measured per-IP budget of 50 requests per hour on the strictest domains, the strict-domain slice alone drives the IP requirement. If those domains represent 120,000 of the daily requests, you need about 2,400 distinct IP touches per hour during the run window. The tolerant domains can be served by a much smaller set of ISP or datacenter IPs at far higher per-IP rates.
Bandwidth: 375,000 HTTP pages at 120 KB is about 45 GB; 125,000 browser pages at 1.2 MB after resource blocking is about 150 GB. Total near 195 GB per day, roughly 5.9 TB per month. That number, not the IP count, is what determines the plan you buy.
Then add margin. Thirty percent headroom on bandwidth and concurrency is a reasonable default, because targets harden, page weight grows, and product teams add requirements mid-quarter.
Capacity Planning Differs by Pool Type
Datacenter proxies give you the highest requests per IP per second and the lowest cost per GB, so capacity plans lean on throughput per IP rather than IP count. They fail on trust: against defended targets, a single flagged IP can drag its neighbours down, so plan for subnet diversity, not just address count.
ISP proxies combine datacenter routing with residential registration, which means you can often push much higher per-IP volume than with rotating residential exits while retaining decent trust. Capacity here is usually expressed in IPs and concurrency rather than gigabytes, which makes forecasting easier for steady, predictable workloads.
Rotating residential proxies invert the model. You do not manage individual IPs; you manage sessions and bandwidth. Capacity planning becomes a bandwidth and concurrency exercise, with the per-IP budget expressed as session length and request count per session.
Mobile proxies carry the strongest trust signal because carrier-grade NAT puts thousands of real subscribers behind the same address, but each IP supports limited concurrency and costs the most per unit of traffic. Plans here are almost always driven by identity count or session count, not throughput.
Most mature operations run a blend, routing each target class to the cheapest pool that clears it reliably. That routing decision is itself a capacity lever: moving 60 percent of traffic off residential and onto ISP for tolerant targets can cut spend substantially without touching success rates.
Session-Bound Workloads Follow Different Math
Everything above assumes throughput work. Account management, social media operations, and multi-profile automation follow a different rule entirely: capacity equals identities, plus spares.
If you run 300 accounts that each require a stable, non-shared IP, you need 300 static IPs, plus a replacement buffer of 10 to 20 percent for IPs that get flagged or retired, plus geographic distribution matching each account's claimed location. Throughput per IP is almost irrelevant because the constraint is one identity per IP over time. Trying to solve this with a rotating pool is the classic sizing error: it looks cheaper per GB and produces a steady stream of verification challenges.
The practical planning question for session-bound work is not "how many requests" but "how many concurrent live sessions, in which countries, for how long?"
Where Capacity Plans Break in Production
Sizing for averages. Peaks are what break systems. If your scheduler fires every job at the top of the hour, your real concurrency is several times your daily average.
Forgetting that targets share the pool. Ten scrapers hitting ten different sites through one undifferentiated pool means an IP burned on one target arrives pre-degraded at the next. Partition capacity per target class.
Confusing advertised pool size with usable capacity. What matters is how many IPs are reachable, in your required geographies, with acceptable reputation, at the moment you need them. Country-level and city-level availability is always a fraction of the headline figure.
Ignoring retry storms. A target that starts returning soft blocks can triple your request volume in minutes if retry logic has no circuit breaker. Cap retries, add exponential backoff, and alert on failure-rate deltas rather than absolute failures.
Rotating too fast. Over-rotation is a capacity problem disguised as a security measure. Changing IP mid-session breaks cookies and trust signals, which raises the failure rate, which increases effective volume.
Instrument the Numbers, Then Re-plan Quarterly
A capacity plan is a living document. The minimum telemetry set: success rate by target and by pool type, bytes per successful request, average and p95 request duration, concurrency actually achieved versus provisioned, and requests-per-IP before first soft block. Log the exit IP with every request so you can reconstruct per-IP histories after an incident.
Before rollout, validate that the IPs you are about to depend on behave the way your plan assumes. A short pre-deployment pass with a proxy tester to confirm geolocation, latency, and leak behaviour is far cheaper than discovering a mismatch through three days of degraded collection.
Where Proxies Fit In
Capacity planning only works if the underlying network can actually deliver what the plan assumes: the right pool type for each target class, real geographic depth in the countries you need, session control that matches your workload shape, and pricing you can forecast against. A plan that requires 700 concurrent Germany-based residential exits is worthless if the provider can supply 700 in aggregate but only 40 in Germany.
This is why pool diversity matters more than raw pool size. Running datacenter for tolerant APIs, ISP for steady medium-trust work, rotating residential proxy pools for hardened targets, and mobile for high-value session-bound accounts lets you route each workload to the cheapest tier that clears it, which is the difference between a plan that scales and one that becomes a line item finance starts questioning.
Ethical sourcing belongs in the capacity conversation too. Pools built on consented peer networks behave predictably over time, while opaquely sourced pools churn and get blocklisted in waves, quietly invalidating every per-IP budget you measured last quarter. When you are converting gigabyte forecasts and concurrency ceilings into a monthly commitment, transparent tiers make the modelling straightforward, and EnigmaProxy is one example of a provider positioned in the professional tier with residential, ISP, datacenter, and mobile options under one account and business-grade reliability across them.
Strategic Shifts to Plan For
Page weight keeps rising. Heavier front ends and more client-side rendering mean bytes per page trend upward every year. Budget for growth in bandwidth even when your page count is flat, and treat resource blocking as ongoing engineering work rather than a one-off optimisation.
Detection is moving from IP to behaviour. As TLS, TCP, and behavioural fingerprinting mature, per-IP request budgets will be set less by volume and more by how human the traffic pattern looks. Capacity plans will increasingly include pacing and session-shape parameters alongside IP counts.
AI agents are changing the load profile. Autonomous browser agents issue bursty, unpredictable, long-lived sessions rather than tidy sequential crawls. Planning for them means provisioning for concurrency variance and session persistence rather than a smooth requests-per-second curve.
Cost attribution is becoming a requirement. Finance teams increasingly want per-project and per-target proxy spend. Sub-account structures and usage analytics are becoming planning tools, not administrative extras, because you cannot optimise what you cannot attribute.
Conclusion
There is no universal answer to how many proxies you need, but there is a repeatable method. Measure effective request volume including retries. Derive concurrency from throughput and latency rather than assuming it. Soak test each target to establish a real per-IP request budget. Multiply requests by bytes to get bandwidth, then add headroom for peaks and target hardening. Size session-bound work by identity count instead of throughput, and route each workload to the cheapest pool type that holds up.
Do that and proxy spend becomes a forecastable input rather than a recurring surprise. The infrastructure underneath still has to hold: geographic depth where you need it, ethically sourced pools that behave consistently, and session control that matches your workload. Providers like EnigmaProxy exist to cover that layer, but the plan is yours to build, and it starts with measuring instead of guessing.