High-volume data collection creates a simple but expensive pricing problem: when a crawler transfers more data, a pay-per-GB bill rises at exactly the same time.
That model can be perfectly reasonable for small or irregular workloads. It becomes harder to forecast when collection runs continuously, retries increase, or several workers operate in parallel.
The two pricing models
1. Pay per GB
The cost is directly tied to transferred traffic:
traffic cost = transferred GB × price per GB
This is easy to understand and often economical for short tests. The drawback is that every retry, duplicate response, large asset, and failed extraction still consumes metered traffic.
2. Throughput-based, unmetered access
A throughput-based plan uses a fixed speed and a fixed duration. The bill is based on the selected capacity and period rather than the number of gigabytes transferred.
“Unmetered” means there is no data cap during the purchased duration. It does not mean infinite instantaneous transfer. The selected throughput remains the capacity constraint.
That distinction matters because a plan should be sized around both traffic volume and the rate at which the application must move it.
A simple break-even calculation
For a fixed-price plan, the traffic level at which it becomes cheaper than pay-per-GB is:
break-even GB = fixed plan price ÷ pay-per-GB rate
Suppose a team currently pays $3 per GB. A workload transferring 100 TB in decimal units is approximately 100,000 GB:
100,000 GB × $3/GB = $300,000
That is an illustrative comparison, not a universal market price. Real rates, taxes, discounts, and billing units vary. The useful part is the formula: replace the assumptions with your own numbers before making a decision.
Check whether the throughput can carry the workload
Cost is only half of the comparison. A fixed-throughput plan must be able to deliver the required volume inside the selected period.
For example, 400 Mbps running continuously for 30 days has a theoretical transfer ceiling of roughly 129.6 TB in decimal units:
400,000,000 bits/s ÷ 8 × 2,592,000 seconds
≈ 129.6 TB
Actual application throughput will be lower. Protocol overhead, target response times, connection setup, retries, geography, and the success rate of each request all reduce the amount of useful data collected.
This is why the best plan is not automatically the fastest one. It is the smallest throughput tier that can complete the real workload with reasonable headroom.
What to include in the comparison
Before changing pricing models, measure:
- Useful traffic, not only total traffic.
- Peak and average throughput across workers.
- Retry volume caused by timeouts, blocks, or invalid responses.
- Session behavior, including rotating and sticky sessions.
- Protocol requirements, such as HTTP, SOCKS5, or UDP over SOCKS5.
- Location availability for the countries or regions being targeted.
- Duration, because a one-day burst and a continuous 30-day pipeline need different capacity.
- Acceptable-use requirements, especially for automated collection and ad-related workflows.
For residential proxy workloads, the available IP pool also matters. A plan can provide access to more than 4 million rotating or sticky residential IPs without charging per individual proxy, while the commercial variable remains throughput and duration.
Use a calculator with editable assumptions
I built a residential proxy cost calculator to make the comparison easier. It lets you change the traffic assumption and compare it against available throughput and duration combinations.
The calculator is most useful as a planning tool:
- Enter a realistic monthly traffic estimate.
- Use the actual per-GB rate from your current bill.
- Select a throughput tier that can carry the workload.
- Add headroom for retries and slower targets.
- Compare the total cost over the same period.
Takeaway
Pay-per-GB pricing is often the simplest choice for experiments and low-volume jobs. Unmetered throughput becomes more attractive when traffic is large, continuous, or difficult to predict.
The right comparison is not “unlimited versus metered” in isolation. It is:
total cost + required throughput + successful data delivered
Once those three numbers are measured, the decision becomes much less subjective.
Top comments (0)