Workload inputs
Count logical rows after application sampling and filtering.
Use a measured serialized payload average when available.
A steady-state planning horizon, not a retention-policy promise.
Aggregate query runtime across the team.
Published paid-plan prices are shown per user per month.
Planning result
3 GB
estimated retained event payload
Free
Over limit
Includes 1 GB and 10 query hours.
Business
$39.00
$36.00 seats + $0.00 storage + $3.00 query.
Enterprise
$297.00
$297.00 seats + $0.00 storage + $0.00 query.
Estimates use published monthly list prices and simple decimal gigabytes. They exclude taxes, discounts, negotiated terms, compression, schema overhead, deletes, and workload changes. This is a planning tool, not an invoice or quote.
Every output is traceable to an input
The calculator deliberately keeps the model simple so the estimate can be checked independently and replaced with measured production values.
- 1
Monthly payload
5,000,000 events × 200 average bytes.
- 2
Retained storage
Monthly payload × 3 months = 3 decimal GB.
- 3
Included usage
Subtract each plan's included storage and 20 monthly query hours before overage.
- 4
Monthly estimate
Add 3 user seats, storage at $0.03/GB-month, and query overage at $0.30/hour.
Calculation model
Reproduce the estimate outside this page
Retained payload is monthly events multiplied by average serialized bytes and retention months, divided by one billion. The calculator uses decimal gigabytes because the published storage allowance and overage rate are expressed in GB.
For a paid plan, seat cost is users multiplied by the current monthly per-user price. Storage and query charges apply only to usage above that plan's included amounts. Negative overages are clamped to zero before the three components are added.
stored_gb = events × bytes × retention_months ÷ 1,000,000,000
storage_overage = max(0, stored_gb − included_gb) × $0.03
query_overage = max(0, query_hours − included_hours) × $0.30
monthly_estimate = seats + storage_overage + query_overage
Scenario guidance
Model volume changes before choosing a plan
High-volume event
Model request or heartbeat events separately. Sampling, aggregation, and a shorter retention period can change their storage contribution by orders of magnitude.
Wide business event
Measure the serialized payload after redaction. A lower-volume canonical outcome can be larger while still costing less than many narrow diagnostic events.
Query-heavy team
Use aggregate runtime across scheduled reports, dashboards, investigations, and automation. Query count alone does not reveal query-hour usage.
Replace assumptions with measured values
- Sample serialized event sizes by event name.
- Count events after sampling, redaction, and retry deduplication.
- Use actual query-runtime usage from the intended team.
- Model retention separately for high- and low-volume tables.