Sizing and scale
How far a single Prelude Collector scales, validated numbers for device and subscription counts, and a simple rule of thumb for sizing the host that runs it.
Rule of thumb
A single collector comfortably handles 1,000 devices and 10,000 concurrent subscriptions. Budget roughly 0.25–0.5 MiB of memory per subscription on top of a ~400 MiB base, plus a couple of CPU cores for headroom during collection bursts. Validated up to 10,000 subscriptions with no dropped data.
A subscription is one model collected from one device over one protocol. A device can carry many subscriptions at once — different models, gNMI and SNMP side by side — so the subscription count, not the device count, is what determines load.
Validated scale
These figures come from a controlled test: one collector against simulated devices, an even split of gNMI streaming and SNMP polling, every target collected on a 10-second interval.
By device count
One subscription per device:
| Devices | Memory | Dropped data |
|---|---|---|
| 100 | ~165 MiB | none |
| 500 | ~355 MiB | none |
| 1,000 | ~655 MiB | none |
By subscription count
1,000 devices, stacking subscriptions per device:
| Subscriptions | Memory | CPU (burst) | Dropped data |
|---|---|---|---|
| 1,000 | ~0.65 GiB | ~20% of a core | none |
| 2,000 | ~0.95 GiB | ~23% | none |
| 4,000 | ~1.6 GiB | — | none |
| 6,000 | ~2.2 GiB | — | none |
| 8,000 | ~2.6 GiB | ~25% | none |
| 10,000 | ~3.0 GiB | ~31% | none |
Memory grows in a straight line with the subscription count, and every level reached full collection with zero dropped messages and zero errors. CPU is bursty: it rises briefly each interval as all subscriptions collect together, then falls back to near idle.
Sizing your host
- Estimate subscriptions, not devices:
devices × models-per-device, counting each protocol separately. - Memory:
~400 MiB + 0.5 MiB × subscriptions, rounded up. For 10,000 subscriptions, plan for ~4 GiB and leave headroom. - CPU: collection is bursty. Two to four cores absorb the per-interval spike for thousands of subscriptions; give more if you also run tight intervals or heavy transforms.
- Interval is a multiplier. Halving the interval doubles the message rate. See Polling intervals for sensible starting points.
What moves these numbers
Model complexity (fields and transforms per update), the number of rows each subscription returns (e.g. interfaces per device), the collection interval, and the output backend all affect CPU and memory. Treat the figures above as a starting point and confirm against your own workload.
When to add a second collector
A single collector covers most deployments. Consider splitting the workload across collectors when you approach the validated ceiling, when you want to isolate a region or tenant, or when one site's interval requirements differ sharply from another's. Each collector is independent — point each at its own slice of the fleet.