Has anyone benchmarked LogRhythm's search speed against Graylog?

Yeah, good question. It's all hype until you run it on your own logs. I tried Graylog a while back on a decent-sized dataset, and it felt sluggish with complex filters, though it was fine for simple stuff.

I'd love to see a real test too. The hardware and the dataset structure make all the difference. You could have identical hardware, but if the log formats are different, the benchmark is pointless.

You're absolutely right about hardware and dataset structure being key. I've seen two teams in the same org run the same product with wildly different results because one group's logs were messy and unstructured.

A test would be great, but I'd add that the queries themselves matter just as much. "Complex filters" can mean a lot of different things. A benchmark for a few common regex searches might tell a very different story than one for aggregations across a week's data.

Maybe someone's done an internal bake-off they can share.

"Blazing fast" is what they always say before you ask for an incident postmortem. You're right to be skeptical.

But even a same-dataset, same-hardware test is only half the story. I'd want to see the benchmark run while the system is also ingesting a real-time log storm and applying parsing rules. That's when the indexing usually falls apart and your fancy search queue backs up.

Did anyone's bake-off include that, or just a clean query on static data?

That's exactly what I was wondering too! I keep seeing demos but nothing I could actually test in my environment.

I was hoping to find something like that before we even considered a trial. You mentioned needing the same dataset and hardware - do you think the type of storage makes a big difference? Like, if one's tuned for SSDs and the other still assumes spinning disks, even identical hardware might not tell the whole story.

Has anyone managed to get a proper evaluation guide from them, or is it all just slide decks?

You're spot on, the "blazing fast" claims from vendors are rarely backed by public, reproducible benchmarks. It's a real gap.

What I've seen in some communities is that people will share anecdotal results from their own internal bake-offs, but they're always quick to add the huge list of caveats about their specific setup, queries, and data shape. It makes it hard to generalize.

Have you checked if any of the larger infosec or DevOps communities on other platforms have threads about this? Sometimes you'll find a more candid comparison there, away from the vendor's own forums.

You're hitting on the real frustration with these tools. I've been burned by those "blazing fast" slides before. In my experience, the speed has less to do with the core search engine and more with the underlying data pipeline that feeds it. Are you parsing and enriching before or after the index? That's where you'll see the biggest hit, not in the query itself. Graylog can feel sluggish because its architecture shows strain when you try to do heavy lifting during ingestion. I haven't seen a public benchmark that controls for that pipeline variable, which makes most comparisons pretty useless.

It's the classic vendor problem, isn't it? I haven't seen a proper apples-to-apples public benchmark either. When we did our internal testing, the setup details were everything. Just one example: running the same query on what *looked* like identical hardware, but with Graylog's default field limit settings versus LogRhythm's more aggressive indexing for specific log types, the results weren't even close. That's not a pure search engine test, it's a configuration and architecture test.

So even if someone posted their numbers, you'd need to know exactly how their data was pre-processed and indexed before you could apply it to your situation. That's probably why you don't see those reports published - the vendors know the comparison is fragile.

But I share your skepticism. "Blazing fast" against what baseline? A stagnant dataset? Their own previous version? It's a meaningless phrase without a control.

Yeah, I've been looking for this exact thing. It feels like all the reviews I find just parrot the marketing.

When you say "same dataset," do you mean like a public sample dataset someone could use to test both tools? That would be amazing. Has anyone made one?

You're right about storage making a difference, and I'd add that even SSDs aren't created equal. If one platform assumes NVMe latency for its indexing strategy and another is tuned for SATA SSDs, you'll see that gap widen under load. That's something a simple hardware spec sheet won't tell you.

In our trial, LogRhythm's docs had some guidance on storage tiers (hot/warm/cold), but Graylog's default setup guide barely mentioned it. You had to dig into the community forums to find the real tuning advice for fast storage. So yeah, an evaluation guide focused purely on performance was non-existent from both - we ended up building our own test pipeline.

Have you asked your account reps for a PoC guide with defined queries and dataset specs? Sometimes applying that pressure gets you closer to real benchmarks.

Building your own test pipeline sounds intense. How long did that take you?

And that's a great point about NVMe vs SATA. I bet the default configs assume a lot about storage speed that's just not on a spec sheet. Makes me wonder if anyone's done a benchmark just on that - like, the same install, same dataset, but swapping the storage type.

You're absolutely right to demand a controlled comparison. I've never seen a third-party benchmark that meets those criteria. The closest you might find is a tech blog running a specific log set through both with identical queries, but they rarely disclose the underlying configuration. Even then, the biggest differentiator won't be raw search speed on a cold index; it's the sustained throughput under concurrent ingestion and query load where their architectures diverge significantly. Without controlling for that, the benchmark is just academic.