Sizing Estimator
Use this calculator to estimate the compute resources (vCPU and memory) required for your Lakerunner deployment based on your expected telemetry throughput.
Telemetry Throughput
Enter your expected telemetry volume. Select a time unit that is convenient for you — all values are normalized internally.
Query Capacity
Query capacity depends on your query patterns, concurrency, and data volume. We recommend a minimum of 2 query-api and 2 query-worker pods.
Estimated Resources
| Category | Pods | Total vCPU | Total Memory |
|---|---|---|---|
| Core Components | 4 | 0.95 vCPU | 0.83 Gi |
| Logs | 2 | 2.00 vCPU | 8.00 Gi |
| Metrics | 4 | 7.00 vCPU | 22.00 Gi |
| Query | 4 | 6.00 vCPU | 16.00 Gi |
| Grand Total | 14 | 15.95 vCPU | 46.83 Gi |
Recommendations
Auto-Scaling
Log, metric, trace, and query components auto-scale automatically based on demand. The estimates above represent a maximum footprint at sustained peak load. Actual resource usage will be lower during normal operation.
Cluster Auto-Scaling
We strongly recommend enabling Kubernetes cluster auto-scaling to automatically add and remove nodes as workload pods scale up and down. This ensures you only pay for the compute capacity you actually need.
Spot / Preemptible Instances
Lakerunner workloads are well-suited for Spot Instances (AWS) or Preemptible VMs (GCP). These can reduce compute costs by 60-90%. All Lakerunner components are designed to handle interruptions gracefully through work queue-based processing.
Query sizing from usage
The estimator above takes the number of query workers as a direct input. If you don’t have a feel for that number yet, this calculator derives it from how your team uses the product — dashboards, alerts, and engineers — and estimates the compute cost across business and off-peak hours.
The model assumes query pods scale down outside business hours, when only alert evaluation drives load. Pods are sized in 4-pod groups, where each group of 2-vCPU / 4-GiB pods handles up to 30 QPS.
Your usage
Three signals drive query load: how many dashboards are open during peak hours, how many alerts are evaluating continuously, and how many engineers are running ad-hoc queries.
Estimated load
| Regime | QPS | Pods | vCPU | Memory | Hours / mo | Cost / mo |
|---|---|---|---|---|---|---|
| Peak (business hours) | 13.7 | 8 | 16.00 | 32.00 Gi | 217 | $104 |
| alerts | 1.7 | |||||
| dashboards | 12.0 | |||||
| ad-hoc | 0.03 | |||||
| Off-peak (alerts only) | 1.7 | 8 | 16.00 | 32.00 Gi | 513 | $246 |
| Total | $350 | |||||
How this is computed
Each pod is 2 vCPU + 4.00 GiB. A 4-pod group handles up to 30 QPS at burst; we multiply expected QPS by a headroom factor (default 3×) to account for slow queries, retries, and latency variance, then round up to whole groups with a 2-group floor for HA across availability zones.
- Alert QPS = alerts ÷ alert eval interval. Runs 24/7.
- Dashboard QPS = min(dashboards, engineers × concurrency) × panels ÷ panel refresh. Peak only.
- Ad-hoc QPS = engineers × queries per engineer per hour ÷ 3600. Peak only.
- Effective QPS = raw QPS × headroom factor; pod groups = max(min groups, ⌈effective QPS ÷ 30⌉).
- Cost = (peak pods × peak hours + off-peak pods × off-peak hours) × $/pod-hour, over a 4.345-week month.
Defaults are calibrated to typical observability workloads; tune them under Show assumptions to match yours.
Reach out to support@cardinalhq.io for support or to ask questions not answered in our documentation.