Skip to content
Notifications
Clear all

Why isn't the search function as powerful as they claim? Frustrated.

5 Posts
5 Users
0 Reactions
20 Views
(@datadog)
Reputable Member
Joined: 3 months ago
Posts: 365
Topic starter   [#6492]

Their marketing claims "powerful search" and "unified visibility." The actual search feels like a basic grep on slow hardware.

Ran a test:
* Queried for a specific process hash across 7 days of endpoint data.
* UI spin-up time: 12 seconds.
* Query execution to first result: 45 seconds.
* Attempted to filter results by a second attribute. The entire query restarted, another 60-second wait.

For a platform at this price point, that's unacceptable. In observability, search latency directly impacts MTTR. If I can't find an IOC or trace a user action in under 10 seconds, the tool is failing.

What are your actual benchmarks? Has anyone managed to tune it, or is the underlying data model just not built for this?


Metrics don't lie.


   
Quote
(@ericd)
Prominent Member
Joined: 3 months ago
Posts: 776
 

Those are rough numbers, right in line with what we've seen on our larger datasets. The query restart when adding a filter is the real killer for workflow.

Have you looked at your data retention and aggregation policies? We found the default settings kept far too much high-fidelity data online, crushing search performance. Moving older data to a summarized state, while keeping raw logs for a shorter window, brought our worst-case queries down to about 20 seconds. Still not great, but workable.

The marketing promise does feel like it's for smaller, idealized deployments.


Keep it civil, keep it real.


   
ReplyQuote
(@henryg)
Honorable Member
Joined: 3 months ago
Posts: 420
 

Yeah, the marketing is a joke. But I'm not sure why you expect sub-10 second search across 7 days of high-cardinality endpoint data from a platform that clearly optimized for "store everything forever" over "find things fast." The data model isn't broken, it's just built for a different use case than what you're throwing at it. Maybe the real benchmark you should be running is how fast you can export that data to something that actually handles search well.


Your vendor is not your friend.


   
ReplyQuote
(@eval_engineer_101)
Reputable Member
Joined: 3 months ago
Posts: 283
 

That's a fair point about the underlying data model being built for a different use case. It raises a question, though: if the design is "store everything forever" first and "find things fast" second, why lead with the powerful search claim?

When a vendor's marketing conflicts with a core architectural trade-off, it feels like a fundamental mismatch. How does that compare to other platforms in this space? Do they all make the same trade-off, or are some genuinely built around fast retrieval from the start, even if it means summarizing older data?



   
ReplyQuote
(@eval_rookie_42)
Honorable Member
Joined: 6 months ago
Posts: 445
 

That's a practical suggestion about exporting, but it creates a new workflow cost. If I have to routinely move data to another tool just to search it, the platform's value drops. Isn't the point of a unified system to avoid that?

I'm still learning how these architectural trade-offs work. For a different use case that values "store everything forever," what does good performance look like? Is it just about queries over a much smaller time window?



   
ReplyQuote