How many GB of residential proxies do you need? Data sizing for monitors, raffles and queues

Static proxies are sized by counting tasks. Rotating residential proxies are billed by traffic, so the question changes shape: not “how many IPs” but “how many bytes”. That sounds harder to answer, and it is, but only until you know the two numbers that drive it. This guide gives you the formula, realistic figures for the common jobs, and a ten-minute way to replace every estimate here with your own.

The formula

Data used = number of requests × average response size. Request headers and TLS handshakes add a few KB each, which only matters when responses are tiny. Everything else in residential sizing is estimating those two factors for your own setup, and the second one varies far more than people expect.

The browser multiplier

The single biggest lever is how your tool fetches pages. A request-mode bot or monitor pulls the HTML or a JSON endpoint and nothing else: tens of KB per hit. A real browser session loads the page plus images, fonts, scripts, analytics and chat widgets, and a modern product page lands between 2 and 5 MB. That is a 20x to 50x difference for the same logical action. Before buying anything, know which mode each of your tasks runs in. A browser-based tool that blocks images and media typically lands somewhere in the middle.

Worked examples

Assumptions are stated so you can swap in your own.

A restock monitor

One SKU, request mode, polling every 5 seconds, 80 KB per response. That is 17,280 requests a day, or roughly 1.4 GB per SKU per day. Ten SKUs at that cadence burn around 14 GB a day, which is why always-on monitoring is the job where sizing matters most. The levers are obvious once the numbers are visible: polling every 15 seconds cuts it to a third, lightweight stock endpoints shrink the response size, and most monitors can sleep during hours when stock never flips. The retail proxies page covers which sites tolerate which cadence.

Raffle and mass-entry runs

One entry in request mode is a handful of requests at 100 to 300 KB each, so budget 1 to 3 MB per entry. Five hundred entries is roughly 1 GB. The same run through full browser sessions is 10 to 30 MB per entry, so the same five hundred entries become 5 to 15 GB. Per-request rotation is the default here, because each entry wants a fresh household.

Ticket queues

A queue session is mostly waiting. After the initial page load, the queue page polls a small endpoint every few seconds, usually under 20 KB a time, so an hour in a sticky session costs on the order of 10 to 50 MB depending on whether the tool renders the page. A hundred queue slots is therefore a few GB, not a few dozen. The detail lives on the ticketing proxies page.

Checkouts that have to run on residential

Most checkouts belong on static ISP IPs (more on that below). Where a site forces residential, a checkout flow is a few MB in request mode and perhaps 20 MB in a browser. Cheap per attempt; the cost is in how many attempts you run.

Measure, do not guess

Every number above is an estimate. Your own figure takes ten minutes: note the GB balance in the dashboard, run your real configuration for ten minutes, note the balance again, and multiply the difference by 144 for a day. Do it once per task type, in the mode you will actually run. Because Porter data never expires, you can buy small for the measurement and bulk afterwards without wasting anything.

Five levers that cut burn

• Request mode wherever the tool allows it. The 20x lever. Reserve browser mode for sites whose fingerprinting demands it.
• Block images and media in browser-based tools. Pictures are most of a product page.
• Longer polling intervals on anything that is not seconds-critical. Restocks are won by being there, not by polling twice as fast as the next runner.
• Lightweight endpoints. Many stores expose a stock or product JSON far smaller than the rendered page.
• One monitor per SKU, shared across tasks, instead of every task monitoring on its own.

What should not be on GB at all

Checkout tasks on Footsites, Shopify and the big-box retailers, and any account you keep across releases, belong on dedicated static ISP proxies: a flat per-IP price, no meter, and the stable identity those sites want. The rule for that side of the setup is in how many proxies do you need. A typical winning setup runs both: ISP for carting and accounts, residential GB for everything that polls, enters or browses at scale.

Which pool, and how much to buy

Core Premium, the household pool, is the default and the cheaper per GB. Core Mobile routes through 4G/5G carrier addresses that sites are most reluctant to block; hold it for the targets where residential feels pressure, since every GB there costs more. Pricing starts at $2.00 per GB at volume, the balance never resets, and top-ups stack onto it, so the right first buy is slightly more than your measured need and the right second buy is whatever tier makes the per-GB price cheapest. Generating proxy lists is free; only traffic counts.