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 at 300 RPS and 25K traces for lighter production indexing |
| Active app backend / moderate backfill | Operator | 45M requests at 300 RPS and 50K traces for steadier event workloads |
| Sustained indexing / multiple contracts | Pro | 90M requests at 300 RPS and 100K traces for heavier monthly usage |
| Production analytics / heavy indexing | Business | 160M requests at 500 RPS and 250K traces for large continuous jobs |
| Temporary backfill spike | Extra 20M request packs | Use extra 20M volume packs (39 USDC) when the spike is temporary |
| Temporary launch / event spike | +100 RPS 72h Burst Pass | Lift peak throughput from 300 RPS to 400 RPS for 3 consecutive days (72 hours) |
When to buy extra volume vs upgrade
- Buy extra 20M 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 a +100 RPS 72h Burst Pass only when peak traffic exceeds 300 RPS during short event spikes.
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 300 RPS enough for an indexer?
Yes. 300 RPS provides generous headroom for concurrent event scanners and live indexing. Sustained indexing capacity depends on your monthly volume tier (20M up to 160M), eth_getLogs chunk sizes, and retry discipline.
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.