Customer workload
Drag a ruler or enter an exact value. Each organization uses the same workload.
Size event history and ongoing event ingestion.
Hetzner estimate
- Average per organization / month
- —
- Fleet total / month
- —
Estimates in USD. ECB reference rate
How the workload fits
Each row groups identical nodes. Resource usage is shown per node.
| Node group | On each node | RAM required | Provisioned disk | Modeled CPU | Disk I/O | Monthly subtotal |
|---|
The estimate assumes balanced data and traffic across partitions. Each partition has one live copy and its own indexes and supporting data. Deployment needs partition-aware routing and benchmarks for queries that span partitions.
Node sizing assumptions
Data and index footprint
Compare one organization with the full deployment at the selected retention.
Evidence, entities, and counters
| Metric | Per organization | All organizations |
|---|
Indexes
| Metric | Per organization | All organizations |
|---|
Entry counts cover evidence records and active counters. Physical indexes also include supporting collections and any extra partitions.
Detailed sizing and model assumptions
Sizing result
Disk by deployment
Per database copy, with rebuild copies and free space allowance.
In Motion counter comparison
Compares monthly event counters with the earlier daily and monthly event counters.
Workload breakdown
Storage and database demand per organization. Shared directory and database allowances are accounted for in the machine and fleet estimates.
Custom machine comparison
| Database role | Disk | Host RAM | CPU floor | Modeled I/O | Against machine |
|---|
Hetzner cost at different workload sizes
At Rest per TB
Incremental estimates exclude fixed directory, journal and host reserves.
| Per 1 TB scanned, per snapshot | Estimate |
|---|
Index inventory
Index definitions follow the app’s shared MongoDB schema. Entry counts are sized separately for events and files.
| Index family | Definitions | Estimated entries | Estimated disk |
|---|
Exact index names in the app
What the counters track
In Motion counters group event activity by month. At Rest counters summarize file inventories by snapshot.
| Workload | Counter group | Time period | Grouped by | Count contributions | Stored counters | Estimated DB updates |
|---|
Model and evidence
In Motion. Saved events equal events received per month × months retained × non-other share. The peak MongoDB write estimate applies the selected multiplier to saved events per month. Historical backfill spreads the saved events across the selected load window.
At Rest. A source scan examines all discovered files. Saved files per snapshot equal classifiable files × non-other share. A full load or snapshot capture writes those retained records. Routine refreshes size writes from changed saved files. Counter rebuilds read the saved records across retained snapshots.
Combined. The planner adds independent event and file workloads to the same deployment. The directory is shared. Entity count sizes directory and counter lookup storage and caps distinct risky actors in each In Motion counter partition.
Indexes. Scalar keys use one entry per row per index. Prefix search expands to the indexed prefix count. Lifecycle flags generate one key per flag, with a placeholder for an empty array. Each stored counter adds an entry to five indexes. Supporting structures are budgeted separately.
Counters. Event counters use monthly buckets. File counters use inventory snapshots for file categories, sensitivity, and inventory dimensions. One record can add to several counters. The simulator estimates how many contributions create separate counters. MongoDB can combine contributions to the same counter into one write within a batch.
Disk and RAM. Disk = (evidence + supporting data + counter copies + journal/oplog allowance) × (1 + scratch %) ÷ (1 − free-space %). Working set uses the hot time range, estimated fractions of data and index pages touched, and decompressed document bytes. Default WiredTiger cache is roughly half of host RAM minus 1 GiB, with a 256 MiB minimum. Filesystem cache, application memory and query peaks need room too. MongoDB WiredTiger
CPU and I/O. Each workload sizes database writes and queries using its own traffic and retained data. The 4-vCPU floor and 16 GiB RAM floor are planning assumptions. Disk I/O is an estimated MB/s budget with amplification. Benchmark latency, random IOPS, and cache eviction separately.
Calibration. Mode-specific averages use 13,019 In Motion events and 15,091 At Rest files from the read-only synthetic fixture. Allocation uses the shared collection’s 48.1 MB of data, 180.4 MB of evidence indexes, and 36.8 MB of counter data and indexes. The sizing scenario uses proposed monthly event and snapshot file counters. Read the calibration and sizing analysis
Reference workloads. The supplied capture’s largest tier-one count is 1,324,426 and may overlap other counts. The M365 At Rest HTML is a separate prototype scenario with 9,986,404 items across about 268 TB. At 1.3 million files/TB, 268 TB would imply 348.4 million files. The two densities describe different populations. This simulator uses the requested density.
Architecture. The Hetzner estimate uses one live copy per database or partition. A separate Node ingest/rebuild worker can isolate the CPU used to build counters. Switching In Motion counters to monthly buckets requires a rebuild from events. Exact day filters need a separate query plan.
Validation. Measure allocated and reusable bytes, P95 latency, keys and documents examined, WiredTiger cache and eviction, replication lag, and rebuild time on a representative isolated load. Use query evidence to evaluate the prefix-search index or an alternative search path. Replica copies increase fleet storage and do not divide primary writes. MongoDB index measurement