Compare
RPC pricing units explained
One RPC call is not always one billable unit. Learn how requests, compute units, API credits, request units, traces, RPS, and monthly volume affect your real Polygon RPC cost.
Built for Polygon builders comparing real workload cost, not just headline RPS.
Pricing models are not automatically good or bad. The problem is comparing them without normalizing request volume, method mix, trace and debug usage, and peak RPS.
Pricing last checked: July 8, 2026.
The short version
Requests
A direct count of RPC calls. Easiest to understand, but the provider still has to decide what counts as a normal request and what counts separately.
Compute Units
A usage weight based on how expensive a method is to process. More flexible, but harder to forecast without method mix.
API Credits
A credit system where methods consume a number of credits. Useful for broad platforms, but users must translate credits into real workload cost.
Request Units
A request-weighting model where full, archive, trace, or historical calls may count differently.
RPS
Peak requests per second. It does not tell you monthly usage by itself.
Monthly volume
How much total usage you can run in the billing cycle.
The main mistake: comparing RPS without monthly volume
- RPS is a peak traffic ceiling.
- Monthly requests are how long the workload can actually run.
- A plan can advertise high RPS but include a smaller monthly quota.
- 30 RPS sustained for 30 days is about 77.76M requests.
- 60 RPS sustained for 30 days is about 155.52M requests.
- 100 RPS sustained for 30 days is about 259.2M requests.
| Sustained average RPS | Requests per 30 days |
|---|---|
| 1 RPS | 2.592M |
| 5 RPS | 12.96M |
| 10 RPS | 25.92M |
| 15 RPS | 38.88M |
| 30 RPS | 77.76M |
| 60 RPS | 155.52M |
| 100 RPS | 259.2M |
If your plan has 30 RPS but only 8M monthly requests, you do not have a full 30 RPS month. You have a 30 RPS ceiling with about 3.1 average RPS over the month.
How BlazingNode counts usage
BlazingNode uses a direct monthly request model for Polygon RPC plans. Buyers see monthly request volume directly, trace calls are shown as included monthly allowances, extra monthly volume is sold as 10M request packs for 35 USDC, and burst is separate from monthly volume for short 72-hour traffic windows.
| Plan | Price | RPS | Monthly requests | Included traces |
|---|---|---|---|---|
| Trial | 0 USDC | 5 | 1M while trial is active | 0 |
| Builder | 49 USDC | 15 | 20M | 25K |
| Operator | 99 USDC | 30 | 40M | 50K |
| Pro | 179 USDC | 60 | 80M | 100K |
| Enterprise | 349 USDC | 100 | 200M | 250K |
This model is not always the cheapest for every small workload, but it is easier to understand for Polygon-only users who want clear capacity.
Compute Units: one request can cost more than one unit
Compute Units are a way to charge based on the computational cost of a request. A simple method can use fewer CUs. A heavy method can use more CUs. This can be fair and efficient, but the buyer needs to understand method mix.
- Alchemy Free includes 30M Compute Units per month and 25 requests per second.
- Alchemy Pay As You Go starts from 300 requests per second.
- Alchemy PAYG is $0.45 per 1M CU for the first 300M CUs, then $0.40 per 1M CU after.
- Alchemy says a simple JSON-RPC call might use 10 CUs, complex operations may use 100+ CUs, and 27 CUs per request can be used as an average planning assumption.
- Alchemy trace and debug examples include debug_traceTransaction at 40 CU, trace_transaction at 40 CU, and trace_callMany / trace_replayTransaction at 80 CU.
10M simple calls at 10 CU/request = 100M CU
10M average calls at 27 CU/request = 270M CU
10M heavier calls at 100 CU/request = 1B CU
The request count is the same, but the billable unit count is not.
API Credits: another way to weight method cost
API Credits are a provider-specific unit. Methods can consume different numbers of credits. Credits can make sense for large multi-chain platforms because not every method costs the same to serve, but the buyer still needs to translate credits into actual workload cost.
- QuickNode Free includes 10M API Credits and 15 RPS.
- Build: $49/month, 80M API Credits, 50 RPS.
- Accelerate: $249/month, 450M API Credits, 125 RPS.
- Scale: $499/month, 950M API Credits, 250 RPS.
- Business: $999/month, 2B API Credits, 500 RPS.
- Extra credits range from $0.62/M credits on Build to $0.50/M credits on Business.
- QuickNode says API credit values are based on method intensity and complex resource factors. Debug and trace methods are billed at 2x the standard credit rate.
- Ankr says 0.10 USD = 1M API Credits. For RPC over HTTPS, Ankr lists EVM-compatible all methods at 200 API Credits / $0.00002 per request.
Do not overgeneralize. Each provider can change credits, method weights, or plan structure.
Request Units: simple until archive, trace, or historical calls enter
Request Units are a weighted request model. They can be easier to understand than broad CU systems, but still require knowing whether the call is full, archive, historical, trace, or debug.
- Chainstack uses Request Units.
- Full requests are 1 RU.
- Archive requests are 2 RUs.
- For EVM chains including Polygon, calls less than 127 blocks behind the tip are full; calls 127 or more blocks behind the tip are archive.
- Historical eth_getLogs, archive calls, and trace/debug can change the billable RU count.
- Developer: $0, 3M request units, 25 RPS.
- Growth: $49, 20M request units, 250 RPS.
- Pro: $199, 80M request units, 400 RPS.
- Business: $499, 200M request units, 600 RPS.
Chainstack is very competitive. The comparison is about buyer fit: Chainstack is a mature broad provider with strong published RPS and RU pricing, while BlazingNode offers Polygon-only plan clarity, included traces, USDC billing, extra request packs, and workload-focused pages and tools.
Trace and debug calls are not normal reads
Trace and debug methods are often heavier because they may inspect execution, replay transactions, read historical state, or expose internal call behavior.
- Some providers gate trace and debug by plan.
- Some providers meter trace and debug with higher unit weights.
- Some providers support debug_* but not all trace_* methods depending on node/client support.
- Buyers should compare trace volume separately from normal request volume.
BlazingNode includes trace call allowances directly: Builder 25K, Operator 50K, Pro 100K, Enterprise 250K.
The unit translation table
| Provider / model | Unit name | What it means | Easy to forecast? | Watch out for |
|---|---|---|---|---|
| BlazingNode | Requests + included traces | Direct monthly request count and trace allowance | High | Polygon-only; plan RPS still matters |
| Alchemy | Compute Units | Method-weighted resource usage | Medium | Method mix, trace/debug, data APIs, throughput CU |
| QuickNode | API Credits | Method-weighted platform credits | Medium | Method multipliers, trace/debug 2x, add-ons |
| Chainstack | Request Units | Full/archive/historical/trace weighted requests | Medium-high | Archive/historical calls can be 2 RU |
| dRPC | Compute Units | Flat 20 CU per RPC method | High | Still usage-based; convert CU to cost |
| Ankr | API Credits / request USD | EVM HTTPS requests priced per call | Medium-high | Advanced APIs, WSS, and gRPC have separate pricing |
Which pricing model fits your workload?
| Workload | Best pricing preference |
|---|---|
| Light dev/testing | Free tiers may be enough |
| Polygon-only production backend | Clear monthly request limits |
| Trace/debug-heavy workload | Included trace allowance or clear trace pricing |
| Multi-chain app needing broad platform APIs | Large platforms like Alchemy or QuickNode may fit |
| Indexer/backfill job | Monthly volume plus eth_getLogs behavior matter most |
| Short event/mint/game spike | Burst capacity separate from monthly volume |
| Continuous scraper | Monthly volume more important than burst |
| Buyer unsure about method mix | Pricing calculator plus workload trial |
Where BlazingNode is designed to win
- Direct monthly request volume
- Clear RPS
- Included trace calls
- USDC pricing
- Extra 10M request packs
- 72-hour burst passes for events
- Workload trial before switching
- Practical fix guides, RPC Checker, pricing calculator, and Polygon-specific use-case pages
BlazingNode may not be the best fit if you need a broad multi-chain platform, advanced non-RPC APIs, marketplace add-ons, or enterprise platform features outside Polygon RPC.
Stop comparing headline prices. Compare your workload.
Estimate monthly requests, peak RPS, trace/debug calls, and method mix. Then test the same Polygon workload before replacing your current provider.
Related paths
FAQ
What is the difference between requests and compute units?
A request is one RPC call. A compute unit is a provider-specific weight that estimates how expensive that call is to process. One request can consume 10, 20, 40, 80, 100+, or more units depending on the provider and method.
Why do providers use compute units or credits?
Not every RPC method costs the same to serve. A simple latest-block call is different from a trace, replay, large log query, or advanced data API call. Units let providers price heavier work differently.
Are compute units bad?
No. They can be fair and efficient. The tradeoff is that buyers need to understand their method mix before they can forecast monthly cost.
Why does BlazingNode use monthly requests instead?
BlazingNode is focused on Polygon RPC workloads and uses direct monthly request limits so buyers can reason about plan fit more easily. Trace calls are shown separately as included monthly allowances.
Is RPS the same as monthly volume?
No. RPS is peak rate. Monthly volume is total usage over the billing cycle. A 30 RPS ceiling does not mean a plan includes a full month of sustained 30 RPS unless the monthly quota is around 77.76M requests.
How do trace/debug calls affect cost?
Trace and debug calls are heavier than normal reads and many providers gate or meter them differently. Buyers should compare trace and debug support and included trace volume separately from normal request volume.
When should I use BlazingNode’s extra 10M request packs?
Use extra packs for temporary or uneven monthly usage, such as backfills, data catch-up, or one-off growth. Upgrade if the higher usage repeats every month.
When should I use a burst pass?
Use a burst pass when peak RPS is temporarily higher for a short window, such as a launch, game event, mint, claim period, or campaign spike. Burst is not a replacement for monthly request volume.