The question comes up in every evaluation, usually phrased as a request for a league table. It deserves a more useful answer than a list, because availability is not a fixed property of a country. It varies by provider, it moves through the day, it differs between country level and city level, and the only figure that affects your project is the one in the specific markets you collect from at the concurrency you actually run.
Here is what determines availability, which countries tend to be deep and which tend to be thin, and how to measure the answer for yourself rather than trusting anybody’s chart.
What actually drives availability
Three factors set how many usable addresses exist in a country at a given moment.
Population and broadband penetration. A residential pool is made of real home connections, so its size in a country is bounded by how many households have broadband and how many of those participate. Large, highly connected countries have deep pools almost by definition, and small or low-connectivity countries do not, regardless of how the provider operates.
How the pool is sourced. Participation comes through disclosed arrangements, usually apps and SDKs, and those have their own geographic distribution. A provider whose supply comes from applications popular in one region will be strong there and thinner elsewhere. This is why two providers quoting similar global totals can differ substantially in the same country.
Time of day. This one is routinely forgotten and it matters. Residential addresses belong to devices that are switched on and connected, so a country’s available pool follows human activity: deeper in local evenings, thinner in the small hours. A job that runs at 04:00 local time in a small market is drawing from a materially smaller set than the same job at 20:00.
The general shape
Without pretending to a ranking that would be stale by next quarter, the pattern is predictable.
Deepest availability sits in large, high-connectivity markets: the United States, the United Kingdom, Germany, France, Brazil, India, Japan, Canada, and comparable economies. In these you can generally run country-level work at meaningful concurrency, and often city-level work in major metros, without thinking about pool depth at all.
Mid-tier availability covers most of Europe, much of Latin America and Southeast Asia, and the larger African markets. Country-level targeting is typically comfortable; city-level targeting outside the biggest cities starts to get thin, and concurrency has a lower ceiling before you begin drawing the same addresses repeatedly.
Thinnest availability is in small countries, sparsely populated ones, and places with limited residential broadband. Country-level work is often fine at modest volume; city-level or ASN-level filtering may return very little, and this is where fallback behaviour and scheduling start to matter.
The useful takeaway is not the tiers themselves but what they imply: match your ambition to the market. City-level targeting across major US metros is routine, while the same approach in a small market may not be supportable at all, which is the judgement call in when city-level targeting matters.
The metric that actually matters
Headline pool figures are close to useless for this decision, because a number covering 195 countries tells you nothing about the one you need. Four things do.
Concurrent availability in your country, meaning how many distinct addresses you can actually be using at once there, rather than how many the network has ever seen. This is what limits a large job in a small market.
Depth below country level, if you need it. City targeting only works where there are enough addresses in that city, and the same applies to ASN targeting when you need a specific carrier.
Stability over time, since a pool that is adequate at 20:00 and thin at 04:00 will produce a job that succeeds in testing and fails on its schedule.
Geolocation accuracy, which is a separate axis entirely. An address can genuinely be in a country while the databases a target uses disagree, so the practical test is whether the target behaves as though you are there, not whether a lookup service says so.
Measuring it yourself
This takes twenty minutes and beats any published figure.
Sample exits in the country you care about and count distinct addresses and distinct organisations across a few hundred requests. Repetition tells you the effective pool for your filter is small; a wide spread of consumer ISPs tells you it is healthy. The same sampling, incidentally, tells you whether the pool is genuinely residential, per spotting datacenter IPs sold as residential.
Then run the sample at the concurrency you actually intend, because availability at one request at a time and availability at fifty in flight are different questions. And run it at the times your job will run, including the unglamorous ones, since that is where thin markets reveal themselves.
Finally, test against a real target rather than an IP-echo endpoint, confirming the site serves you local content in the local currency and language. The full method is in testing speed, success rate and location accuracy.
Working with a thin market
When a country genuinely does not have the depth you want, several things help before you conclude it is impossible.
Broaden the filter. Drop from city to region, or region to country. Most of the time the geographic precision you asked for is finer than the data actually requires.
Understand the fallback. By default, when nothing matches a very narrow filter at that moment, the gateway falls back to a broader pool so the request still completes, which is usually what you want. When an exact match matters more than the request succeeding, strict-true makes it return a 502 instead, and knowing which behaviour you are getting is important: a silent fallback in a geo-sensitive job produces plausible, wrong data.
Lower concurrency and lengthen the window. A thin market often supports the volume you need, just not the rate. Spreading the same work over more hours can turn an impossible job into a routine one.
Schedule for local activity. Running when the country is awake gives you a deeper pool for free.
Reconsider the requirement. Sometimes country-level data is genuinely sufficient and the city-level requirement came from habit rather than need.
The bottom line
There is no stable ranking of countries, and a global pool figure answers a question nobody is really asking. Availability is set by broadband penetration, by how a provider sources its supply, and by the time of day, which is why large connected markets are consistently deep and small ones are not, and why the same country can look different at 04:00 and 20:00. What matters for your project is concurrent availability in your specific markets, depth below country level if you need city or ASN precision, stability across the hours you run, and whether targets actually treat you as local. Measure those yourself on a small purchase rather than trusting a chart, and when a market is thin, broaden the filter, decide deliberately between fallback and strict matching, lower the rate rather than abandoning the market, and run when its residents are online.
Across residential proxies the pool spans 195 countries with country, region, city and ASN filters and a documented fallback, and per-GB pricing means the availability testing described above costs only the bandwidth it uses.