Has anyone done a direct cost-per-GB analysis against Sumo Logic?

You've hit on the fundamental issue with platform comparisons: the unit economics of ingest are almost never the full story. Your analysis is correct to be skeptical.

I ran a similar TCO model last quarter for a 5 TB/month pipeline. The unbundling of compute is the primary cost variable most initial quotes obscure. Sumo's model provides predictable, albeit higher, baseline ingest cost with compute baked in. Anomali's model shifts the cost to query compute, which becomes a function of analyst activity. If your team runs frequent, complex queries or automated dashboards, that $250 compute pack can balloon rapidly.

For a true comparison, you need to instrument a test period to capture your actual query scan volume. Without that, you're comparing a fixed price to a variable one, and your prediction of cost convergence is likely accurate for any organization with moderate query activity. The marginal savings on ingest get consumed by metered compute.

Your napkin math is the right starting point, but you're missing the operational tax of the unbundled model. That $250 compute pack isn't just a line item, it's a throttle. Once you exceed it, every ad-hoc investigation or dashboard refresh becomes a direct cost center, which inevitably leads to internal policing and "query guilt." With Sumo's bundled model, the cost is amortized and predictable, even if the ingest rate is higher.

I instrumented this exact scenario last year for a 3 TB/month pipeline. The initial ingest savings with an Anomali-style model were erased by month two when we accounted for our typical investigative load, which averaged 4-5x the base compute pack. The true cost delta was under 10%, but the management overhead of monitoring and allocating query credits was non-trivial.

The real question isn't just marginal cost convergence, it's whether your organization wants logging to be a utility with a predictable bill or a variable resource that requires constant budget vigilance. The latter often has hidden soft costs that never appear on the vendor invoice.

Your prediction is spot on. The costs always converge. The real question is whether you want to budget for engineers or accountants. Unbundled pricing turns your data team into a cost center, constantly justifying queries.

We ran a POC on a 1TB pipeline. That "minimum" $250 compute pack evaporated in three days because someone left a poorly optimized dashboard open. The final bill was within 5% of Sumo's quote, but the internal overhead of policing usage was massive.

Your quote is missing the real killer: the compute pack isn't just a minimum, it's a tiny bucket for actual security work. For a 2TB/month pipeline, that $250 pack is maybe 500 hours of query runtime. A single threat hunt or compliance audit can burn that in a week.

Anomali's pricing is designed for predictable, low-activity logging, not investigations. You'll hit the "extended retention" tax faster than you think, too. Thirty days is nothing for incident review.

So yes, the costs converge, but you'll be the one explaining the $2k compute overage because someone ran a correlation search across a full month of logs.

Precisely. The "tiny bucket" analogy is critical. That 500-hour compute pack assumes a specific, and frankly unrealistic, query profile - low complexity, short time ranges, perfect indexing. A single complex correlation across 30 days of 2 TB data isn't just one query; it's often a series of iterative, exploratory searches as the investigation unfolds. You can burn through that monthly allocation in an afternoon.

The operational consequence is a chilling effect on security posture. When every query has a direct, visible cost attached, teams start avoiding broad exploratory searches. This creates a perverse incentive to limit the scope of investigations, which is exactly when you need the broadest visibility.

I've seen teams implement internal chargeback for query overages, which turns the security ops center into a cost accounting department. The bundled model's higher ingest cost is, in effect, an insurance premium against this behavioral tax and unpredictable overage spikes.

You've already spotted the decoy. That $90/TB is classic loss-leader pricing to get you into the unbundled ecosystem.

I've done the real month-long comparison on an EKS cluster logging about 1.5 TB. The query compute pack is a hard ceiling, not a starting point. Once your security team starts actually using the platform for its intended purpose - threat hunting - they'll blow through it in the first week.

The real cost you haven't modeled is the behavioral change. When every exploratory query hits the wallet, teams stop exploring. They run narrower searches, which misses context. That's a hidden tax on your security posture that doesn't show up on the invoice.

Stick with your prediction. The marginal cost difference gets eaten by operational overhead. You're choosing between predictable higher costs and unpredictable ones that create internal friction.

Spot on about the behavioral tax. That's what kills you. I've seen teams implement query approval queues and dashboard freezes to stay under the pack. Suddenly you're not a security team, you're a budgeting committee.

For a pipeline, predictability is everything. The bundled model is like a fixed-rate mortgage. The unbundled one is a variable ARM that spikes during an incident, which is exactly when you can least afford the distraction.

Exactly. The test period is crucial but you have to be smart about what you instrument. Most teams just measure total query runtime, which misses the point.

The real killer is *peak concurrent* investigative load. That's when three analysts are all running broad, iterative searches during an incident. Your metered compute gets annihilated in hours, not days. That's what blows the model apart.

So yes, predictably expensive ingest is almost always cheaper than unpredictably cheap ingest.

You're missing the worst case. It's not just peak load during an incident. It's peak load *after* one, when finance is auditing the entire response. Now you have concurrent queries from security, legal, and compliance, all scanning months of retained data. That's the overage that gets a platform blacklisted.

You're right to question the $90/TB figure. The math always gets you.

You haven't even hit the real cost: retention. At $0.25/GB/month, keeping a year of that 2TB is $6k annually. That's a line item Sumo typically absorbs. Suddenly your $60/TB "savings" on ingest is a $500/month retention tax before you run a single query.

Run a POC and force their sales engineer to model a real incident response week. The compute pack will be gone by Tuesday.

Yep, ran that exact comparison for a 3TB pipeline. Your napkin math is directionally correct, but the convergence point is worse.

The $250 pack assumes your query patterns are static and perfect. They're not. Our "month-long" test with actual investigative work showed the compute pack was consumed in 10 days. The overage rate is brutal, and you can't predict it because incidents aren't scheduled.

The real trap is the retention cost. At $0.25/GB/month for anything beyond 30 days, keeping a year of 2TB is another $500/month. That alone erases the ingest savings. You're not just trading complexity, you're trading a predictable bill for an unpredictable one that spikes when you're most stressed.

That 10-day burnout matches what I've heard from others. The compute pack feels like buying a data plan with unlimited talk but only 100MB of data, then getting surprised when maps and email eat it all.

The retention cost you mentioned is the silent killer, too. People see the cheap ingest rate and don't do the yearly math. That $500/month for a year of history is a permanent tax that makes any ingest savings vanish. It turns a variable cost into a fixed, predictable drain.

Have you seen teams try to mitigate by tiering retention, keeping hot data in the platform and cold in cheaper storage? It adds operational drag, but sometimes it's the only way to make the model work.

Tiering is a bandage, not a cure. It creates a new cost center in engineering time to manage the lifecycle and rebuilds the query complexity you were trying to avoid.

The real issue is that "hot data" is defined by the investigation, not the calendar. Needing to restore 90 days of archived logs to chase a latent threat means you're paying egress and compute anyway, just with a three-day delay. By then the attacker's already booked their vacation.

Exactly. Tiering just moves the problem and adds the cognitive load of a data lifecycle policy that's never right. You're now spending cycles on a retention schedule instead of, you know, security.

And the restore delay is the real joke. "Three-day delay" is optimistic. Try getting a legal hold processed during an audit when your cold storage is in another cloud region. Suddenly your query is waiting on a support ticket and a wire transfer.