Security Data Works

Service Offering 3 · Economics

The cost model the design track actually runs on.

Every number on this page assumes one explicit reference workload: a 10,000-employee enterprise, 500 GB/day of raw log volume, a 365-day retention requirement, a 10× compression ratio (Parquet plus ZSTD), and US-East region pricing. I state the assumptions first because the economics only mean anything against a fixed workload. Change the volume, the retention, or the region and the comparison shifts. That is why the design engagement re-runs this model against your real data instead of quoting these figures back to you.

The MOAR monthly cost

Eight line items, decomposed to the instance type.

Here is the MOAR Stack monthly cost at the reference workload, line by line. I show the sizing behind each figure rather than a rolled-up total, because the only honest way to defend a cost model in procurement is to expose the instance types and the utilization assumptions and let the reviewer argue with them.

Component Service / Sizing Monthly Cost
Storage (after 10× compression) 18.25 TB × $0.023/GB $420
Polaris Catalog (managed) Serverless, pay-per-call $50
Tenzir (self-hosted) 2 × m5.xlarge $280
StarRocks (self-hosted) 4 × r5.2xlarge $1,520
Trino (auto-scaling) avg 2 × r5.4xlarge at 50% utilization $760
Spark (EMR, scheduled) ~40 hours/month × $2/hour $80
Grafana Cloud (Pro) 10 users $300
Data Transfer (S3 → compute, optional) 500 GB/day × 30 days × $0.01/GB $150
Total $3,560/month
Total (single-AZ, no transfer costs) $3,410/month

Normalized against ingest, that is an effective $0.24/GB ingested ($3,560 over 15,000 GB/month). I report the per-GB figure because it is the unit procurement teams compare against, but the headline takeaway is structural rather than per-unit: most of this bill does not move when query load moves, which the cost decomposition below makes explicit.

The SIEM comparison

The same 500 GB/day at 365-day retention, priced six ways.

The comparison only holds at a fixed workload, so this table prices the same 500 GB/day and the same 365-day retention requirement across the platforms a 10,000-employee program would actually shortlist.

Platform Monthly Cost Notes
Splunk Cloud $8,333–$15,000 Managed, unlimited queries, 90-day standard retention
Splunk Enterprise TCO $54,167–$100,000 Self-hosted plus infrastructure plus 2–3 admins
Azure Sentinel (complete) $31,000–$35,000 Ingestion (~$12K) plus retention (~$18K) plus search jobs ($1–5K)
Azure Sentinel (short retention) $12,000 Ingestion only, ≤90 days, light investigations
Elastic Stack $15,000–$30,000 Self-hosted, 6–8 hr/week ops burden, hot storage costs
Humio / LogScale $6,250–$12,500 Estimated, unlimited-ingest model (contact sales)
MOAR Stack $3,560 Fixed compute, unlimited queries, vendor-neutral

Stated as reductions against the 365-day-retention equivalents: roughly 89–90% versus Azure Sentinel complete TCO, 68–82% versus Splunk Cloud, 93–97% versus Splunk Enterprise TCO, and 78–89% versus Elastic Stack. Those are large gaps and they hold across the band, which is why MOAR is a defensible recommendation at this workload.

Humio is the honest exception. Against Humio/LogScale at $6,250–$12,500/month, MOAR ranges from roughly −50% to +46%, meaning Humio may be cheaper than MOAR at this volume. I keep that line visible rather than dropping the unfavorable comparison. Humio's flat unlimited-ingest model is competitive at 500 GB/day, and a procurement review that only saw the favorable rows would be right to distrust the whole table. The case for MOAR over Humio is not price at this volume; it is vendor neutrality, multi-engine optionality, and the cost curve at higher volumes and longer retention.

Cost decomposition

Compute is fixed. Storage is the part that scales.

The structural property that makes the MOAR economics behave differently from SIEM economics is where the money sits. Two-thirds of the bill is fixed compute that does not move with query volume. Only the storage line scales, and it scales with retention rather than with investigation load.

Component Monthly Cost % of Total Behavior
Compute (StarRocks, Trino, Spark) $2,360 66% Fixed — unlimited queries within capacity
Storage (S3 plus compression) $420 12% Scales with retention period
Infrastructure (Tenzir, Polaris, Grafana) $780 22% Mostly fixed (catalog, visualization, routing)
Total $3,560 100%

Compute is fixed at $2,360/month regardless of how many investigations run against it. That is the same structural property the SIEMs have for query (Sentinel bundles unlimited Analytics Logs queries then charges $0.0062/GB for search jobs; Splunk and Humio bundle queries into the ingestion or annual rate; Elastic's query capacity is whatever the cluster is sized for). The difference is that MOAR's storage line, which is the only part that scales, scales with the retention horizon rather than with analyst activity, so a program that needs 365-day retention does not pay a query-volume penalty for having it.

Query-volume behavior

Investigations cost MOAR nothing — until they exceed the provisioned capacity.

Here is where the fixed-compute property shows up in the bill. Take Azure Sentinel as the comparison, with search jobs at roughly $6.20 per 100 GB scanned. At 10 investigations/month (100 GB scanned each), Sentinel adds about +$62/month. At 100 investigations, about +$620/month. At a heavy SOC workload of 1,000 investigations/month, about +$6,200/month. Over the same range, MOAR adds $0 in additional cost, because queries do not carry a per-scan charge.

I have to state the caveat plainly, because "unlimited queries" is the kind of phrase that gets a cost model thrown out of procurement when it turns out to be conditional. It is conditional. "Unlimited" means no per-query charge; it does not mean infinite capacity. The compute is fixed at the provisioned 2× r5.4xlarge Trino nodes (32 vCPU, 256 GB RAM total). That sizing handles roughly 20 concurrent analysts or about 100 queries/hour. Past that point you get query queuing, not a surprise invoice. The fix is to add Trino nodes at $760/month each, which is a capacity decision the design engagement sizes against your actual concurrency profile rather than a number I will pretend is unbounded.

Given that structure, the MOAR economics improve under three specific conditions:

  • High investigation workloads, where there are no per-query charges within the provisioned capacity.
  • Long retention periods, where storage scales linearly while compute does not.
  • High data volumes (above roughly 1 TB/day), where SIEM ingestion costs escalate fastest.

These are modeled, illustrative numbers at the stated assumptions, not a quote. The published benchmark is the measured performance side of the same architecture, and this page is the modeled cost side. As cloud and vendor pricing shifts, the model gets re-tested in ongoing research, and the Migration Assessment is the engagement that projects this model against the prospect's actual workload rather than the reference workload above.

When each platform makes sense

MOAR is the right answer for a specific shape of program, not for every program.

A cost comparison that only ever recommends the thing it is selling is not a cost comparison. Here is the honest decision guide I use in the engagement, naming the conditions under which each platform, including the ones MOAR loses to, is the correct choice.

Choose Azure Sentinel when

Choose Splunk when

Choose Elastic Stack when

Choose Humio / LogScale when

Choose the MOAR Stack when

The staffing caveat

The $3,560 figure does not include the people who run it.

Every infrastructure number on this page excludes staffing, and that exclusion is large enough that I will not let it sit in a footnote. The MOAR Stack is operated software, not a managed SIEM, and the people cost is part of the real total. Leaving it out is the kind of omission that makes a 70–90% reduction claim collapse under a serious TCO review.

  • 1–2 security data engineers to run the stack at $150K–$300K annually. That is loaded headcount, not a tooling line, and at the low end of the SIEM comparison it can exceed the infrastructure savings on its own.
  • A 3–6 month learning-curve productivity hit. The team gets slower before it gets faster while Iceberg, Trino, and StarRocks operational practice is being built.
  • Ongoing maintenance with no managed-service backstop. Iceberg compaction, StarRocks tuning, and the rest of the steady-state operational work continue for as long as the platform runs.

This is why the design track exists and why the Migration Assessment models staffing alongside infrastructure against the prospect's real workload. A program without data-engineering capacity, or one whose volume and retention are modest enough that Humio or short-retention Sentinel already win on price, may be better served by one of those platforms. I would rather say so here than have a procurement reviewer discover it for me.

The model only matters when it runs against your data.

These are modeled illustrative numbers at the stated reference workload, not a quote. The intro call confirms the engagement shape; the assessment runs this model on your real volume, retention, and concurrency profile.