Use cases
Polygon RPC for indexers and event-driven backends
Backfills, event scans, and production monitors fail differently from normal app reads. BlazingNode gives Polygon indexers clear monthly volume, included traces, and predictable RPC limits for serious workloads.
Last updated: July 8, 2026.
Use-case navigation
Who this page is for
Why indexers stress RPC differently
- Backfills generate sustained request volume.
- eth_getLogs becomes heavy depending on range and event density.
- Retry storms multiply usage.
- Shared endpoints can pass spot checks but fail at p95 and p99.
- Indexers need resumable state and predictable limits more than flashy peak RPS.
| Failure mode | What it looks like | What to fix |
|---|---|---|
| eth_getLogs timeout | Job stalls | Chunk ranges and test provider behavior |
| 429 during catch-up | Parallel workers or retries get clipped | Throttle and budget request concurrency |
| Stale latest block | Missed or delayed events | Monitor block freshness |
| Random p95 spikes | Slow sync and duplicate retries | Compare tail latency, not just averages |
| Trace/debug unavailable | Failed transaction analysis is blocked | Use a plan with included traces |
| Monthly quota exhaustion | Job stops mid-cycle | Add extra volume packs or upgrade |
The indexer architecture BlazingNode is designed for
Backfill month? Use extra volume, not burst.
Technical checklist before testing BlazingNode
- Know current monthly request count
- Estimate average RPS and peak RPS
- Identify top 5 methods
- Measure eth_getLogs chunk size
- Record p95 and p99 latency
- Count trace and debug calls
- Separate backfill and live polling
- Set checkpoint and resume logic
Plan recommendations for indexers
| Workload | Suggested plan | Why |
|---|---|---|
| Small monitor / early indexer | Builder | 20M requests and 25K traces for lighter production indexing |
| Active app backend / moderate backfill | Operator | 40M requests and 50K traces for steadier event workloads |
| Sustained indexing / multiple contracts | Pro | 80M requests and 100K traces for heavier monthly usage |
| Production analytics / heavy indexing | Enterprise | 200M requests and 250K traces for large continuous jobs |
| Temporary backfill spike | Extra 10M request packs | Use extra volume when the spike is temporary |
| Temporary launch / event spike | 72-hour burst pass | Use only if short-term RPS is the real constraint |
When to buy extra volume vs upgrade
- Buy extra 10M request packs for a temporary backfill, one-time migration, or uneven month.
- Upgrade when the higher volume repeats every month.
- Use trace add-ons when traces are the constraint, not normal request volume.
- Use burst pass only when RPS is the short-term constraint.
Why not just use public RPC?
Public RPC is fine for learning and low-frequency tests. Production indexers need predictable request capacity, clearer limits, and a provider path that behaves more consistently during repeated, historical, or backfill-heavy workloads.
Related links
FAQ
Is 15 RPS enough for an indexer?
Sometimes for a small monitor or early indexer, but sustained indexing usually depends more on monthly volume, eth_getLogs behavior, and retry discipline than a headline RPS number.
How many requests does an indexer use?
It depends on chunk sizes, polling frequency, retries, and how many contracts or ranges you scan. Backfills can consume far more than steady live polling.
Should I use extra volume packs or upgrade?
Use extra volume for a temporary backfill or uneven month. Upgrade when the higher request level repeats every billing cycle.
Can BlazingNode handle backfills?
BlazingNode is designed for serious Polygon workloads, but backfills still need chunking, checkpoints, retries, and realistic request budgeting.
Does BlazingNode support trace/debug for indexers?
Yes. Paid plans include trace allowances, which helps when indexing flows need transaction-level investigation.
Should I separate backfill from live indexing?
Yes. Separating backfill from live polling makes it easier to control retries, budget requests, and avoid sync delays.