One Proxy Vendor or Several: Volume Discounts vs Redundancy

Spending under roughly $500 a month? One vendor. The discount tiers at that level are shallow, but the second integration, the second minimum commitment and the second support relationship are all full price. You will spend more managing the split than the split can possibly save or protect.

Running a pipeline where hours of downtime cost real money, and spending enough that a second vendor's floor is noise? Two vendors, both live, with the secondary carrying a small but non-zero share of daily traffic every day. A standby you never route through is not redundancy, it is an untested assumption.

Sitting between those? Buy one vendor and spend the effort you would have spent on the second on making your switching cost low instead. Our guide to switching proxy providers without downtime is the cheaper version of the same insurance.

Four things, and only the first is on the invoice.

The best tier you qualify for. Consolidation is the only reliable way to move up a discount ladder. Your buying power is the total you place with one vendor, and splitting it always moves you down.

Support attention proportional to spend. This one is underrated. A vendor's escalation path is not neutral. If you are their 40th largest account, your ticket is handled differently from how it would be handled if you were their 15th. Splitting your spend across two vendors makes you a mid-sized account at both instead of a significant one at either, and that shows up exactly when something breaks.

One vocabulary. One error-code set, one auth scheme, one dashboard, one billing cycle, one set of rate-limit semantics. Every one of those is duplicated when you add a vendor, and the duplication is permanent.

A cleaner negotiation. You cannot credibly ask for a discount on volume you have already split away. The strongest position at renewal is holding all of it and being able to move all of it, which is the subject of our post on negotiating proxy volume discounts.

Read an actual ladder and the fear of losing a discount shrinks fast. Webshare publishes a per-proxy volume ladder on its static residential page. Read on 23 September 2026, it ran like this:

Now price a split on it. Say you need 2,000 addresses.

• All 2,000 with one vendor at the $0.255 tier: $510.00 per month.
• Split 1,000 and 1,000 across two vendors on the same ladder: two lots of $270.00, so $540.00 per month.
• The split costs $30.00 a month, which is 5.9 percent more.

At the top of the ladder it is barely worse. Ten thousand addresses at one vendor is $2,250.00. Split into two lots of 5,000 at $0.24 each, the total is $2,400.00, a difference of $150.00 a month or 6.7 percent.

That is the number people are afraid of, and it is under 7 percent in both cases. The reason is structural: published ladders are shallow. This one spans 25 percent from top to bottom across a 500x range in quantity, so halving your volume at a vendor moves you one or two rungs, not to the bottom.

Two caveats before you use 6 percent as your planning figure. First, negotiated enterprise rates are steeper than published ladders, so a split can genuinely cost more if you had a bespoke deal. Second, ladders come in two shapes, and the difference matters: a retroactive ladder reprices every unit at the tier rate you reach, while a marginal ladder prices each block separately. The Webshare ladder above is retroactive, because the per-proxy rate applies to the whole quantity. Ask which shape you are on before modelling anything.

Here is where the multi-vendor case usually gets oversold. The textbook argument says two vendors at 99.5 percent availability each give you 99.9975 percent combined, so your monthly downtime drops from about 3 hours 36 minutes to roughly one minute.

That calculation assumes the failures are independent. They are not, and the assumption is doing all the work.

Model it honestly instead. Split your failure budget into a correlated part and an independent part. Correlated failures include: your own code and configuration, the target deciding to block a technique rather than a network, a bot-management vendor updating its rules across every site you touch, and the case where both of your proxy vendors resell capacity from the same upstream network. That last one is more common than the marketing suggests, and our post on whitelabel and reseller proxy networks explains how to check.

Take a 0.5 percent monthly failure rate per vendor, and assume, purely as an illustrative assumption you should replace with your own, that half of it is correlated across vendors:

• Correlated portion: 0.25 percent, which two vendors cannot help with at all.
• Independent portion: 0.25 percent each, which drops to 0.000625 percent when both must fail together.
• Combined: about 0.25 percent, or roughly 1 hour 48 minutes of a 30-day month.

So the second vendor takes you from 3 hours 36 minutes to about 1 hour 48 minutes. It halves your downtime. It does not remove it, and it gets nowhere near the one minute the naive calculation promises. These are assumption-driven figures, not measurements from any test we ran.

Halving downtime is still worth paying for, if downtime costs you something. Put a number on an hour of your pipeline being dark, then multiply by the 1.8 hours a month the second vendor gives back in this model. At $50 an hour that is $90 of expected loss avoided, against the $150.00 a month the split costs on the 10,000-address example above. Bad trade. At $2,000 an hour it is $3,600 avoided against the same $150.00, which needs no further analysis. There is no general answer, only your number. Our explainer on proxy uptime and reliability covers how to measure the input rather than guess it.

This is the finding that surprised us most when we ran the ladder arithmetic, and it inverts the standard advice about carving volume into an 80/20 primary and secondary.

Take that 10,000-address buyer again, on the retroactive ladder above.

Splitting to 9,000 costs $2,430.00 and drops the primary out of the top tier, so every one of those 9,000 addresses reprices upward. Keeping the primary at 10,000 and buying 1,000 more from a second vendor costs $2,520.00, which is only $90.00 more, and gives you 1,000 extra addresses plus a live second network. The per-address cost is lower on the third row than the second.

The rule that falls out: on a retroactive ladder, find the tier boundary your primary sits on and do not cross it downward. Buy the secondary as additional capacity rather than reallocated capacity. Ten percent extra spend buys a second vendor and headroom, where a nine-to-one split buys a second vendor and a repricing penalty.

On a marginal ladder this does not hold, because dropping volume at the primary only reprices the top block. Confirm which shape you are on first. It is one email to your account manager.

Not every vendor sells a per-unit ladder. Flat plans priced by concurrency behave differently, and SparkProxy's own published pricing is a clean example to work through:

All four are unlimited bandwidth with 30 days validity. The per-thread cost falls 41 percent from Starter to Plus, which is a steeper curve than the per-proxy ladder in the previous section.

Now split on it. You need 1,000 threads.

• One Plus plan: $440.00 a month.
• Two Boost plans: $480.00 a month, which is 9.1 percent more for the same 1,000 threads.
• Four Starter plans: $300.00 for only 400 threads, which is worse on both axes than a single Boost at $240.00 for 500.

The 9.1 percent for two Boost plans is the same order of magnitude as the ladder split, so the headline conclusion survives. What does not survive is the small-buyer case. Plan-shaped pricing has a floor, and splitting means paying two floors. A team that needs 100 threads pays $75 at one vendor and would pay $75 plus whatever the second vendor's entry plan costs to have any redundancy at all, which can easily double the bill to protect a workload that was never worth protecting at that price.

That is the honest reason small teams should not run two vendors, and it is a pricing-structure reason, not an engineering one.

The discount loss is the visible cost and usually the smallest one. Five others show up later.

1. A second integration, permanently. Two auth schemes, two error vocabularies, two sets of rate-limit semantics, two SDK versions to keep current. This is not a one-week task, it is an ongoing tax on every change you make to the fetch layer.
2. Two minimum commitments. Covered above. On plan-shaped pricing this is often the single largest line.
3. Halved support standing. You are a mid-sized account at two vendors instead of a large one at either. The practical effect appears during an incident, which is the one moment you added the second vendor for.
4. Two of every process. Two contracts, two SLAs, two renewal dates, two acceptable-use policies, and in many cases two KYC reviews. Our enterprise proxy procurement checklist is one pass per vendor.
5. Reconciliation. Two invoices, two usage exports in different shapes, two sets of numbers to explain to finance when the total moves.

None of these are reasons not to split. They are reasons to price the split at more than the discount you lose, which is where most of these decisions go wrong.

The strongest argument for using multiple proxy providers is usually not redundancy at all. It is coverage.

Networks differ in which targets they clear. A vendor whose exits sit in ASNs your target has already flagged will fail on that target no matter how good the vendor is, while a second vendor's network walks straight through. This is a capability difference, not a reliability one, and no amount of uptime engineering at the first vendor fixes it.

Three other coverage reasons worth the second contract:

• Geography. Country coverage is uneven, and the vendor who is strongest in the United States is often not the one with usable exits in the market you just expanded into.
• Product type. Almost nobody is best at everything. A datacenter-first vendor and a residential specialist is a very common and entirely sensible pairing.
• Price discovery. Running a live second vendor means you always know what the market rate is, rather than finding out at renewal. That is worth something on its own.

If coverage is your reason, size the second vendor to the workload it uniquely serves rather than to a redundancy percentage. The split then falls out of the requirement instead of being invented.

If you do split, four operating rules decide whether the money was wasted.

Route real traffic through the secondary every day. Ten percent is plenty. A path you exercise daily is a path you know works. A cold standby fails on the day you need it, usually on an expired credential or a changed error format nobody noticed.

Keep the two vendors' failure signals separate in your metrics. If your dashboard shows one aggregate success rate, you cannot tell a vendor problem from a target problem, and you will fail over for the wrong reason. Tag every request with its vendor.

Check for shared upstream before you trust the redundancy. Resolve a sample of exit addresses from both vendors and compare the announcing ASNs. If they overlap materially, you bought one network twice. Our guide to spotting a fake proxy provider covers how to run that check.

Align the contract terms. Two vendors on different renewal dates and different commitment lengths means you are never free to move either one. Our post on monthly versus annual proxy plans covers the trade, and the multi-vendor version is simple: keep the secondary monthly so it stays a lever rather than becoming a second lock-in.

For most teams reading this, one vendor plus a genuinely low switching cost beats two vendors plus the overhead. Test the switching cost rather than assuming it. If you can point your fetch layer at a different network by changing configuration and nothing else, you already have most of what the second contract would have bought you.