Security information and event management (SIEM) platforms have long served as the foundation of security operations. But growing data volumes, increasingly diverse telemetry and rising expectations for faster detection and investigation are putting new pressure on traditional architectures. For security teams, the challenge has grown from simply collecting more data to maintaining complete visibility without unpredictable costs, operational complexity or infrastructure demands that pull skilled resources away from higher-value security work. At the same time, organizations are under pressure to do more with fewer resources while demonstrating measurable value from every technology investment.
Tech Channels sat down with Gravwell's Dan Wheatley, VP of Sales, and Mike Wade, VP of Customer Success, to explore the operational and financial challenges organizations face with traditional SIEM platforms. They discuss how architectural and licensing decisions can affect data visibility, analyst productivity, scalability and cost predictability, and how a more flexible approach to security data can help teams spend less time managing their SIEM and more time investigating threats, improving detections and strengthening security posture.
Mike Wade: When I think of legacy SIEM architectures, I think of schema-based ingestion: when data comes into the platform, it must fit a schema before it gets indexed. That kind of architecture limits flexibility because if you want to use that data later and it changes, you can't. So the fields you add or remove, or how you interact with the data, might change, but if the data is already indexed, you can't change it.
Dan Wheatley: If you have this load on the front of your system, such as ingest, like an ingest pipeline where your schema is on ingest, you have to do the processing upfront, and you're paying that cost per record up front. Your ingest pipeline can also slow ingestion, which means you get access to the data more slowly. If you have downtime, you could possibly lose data. If you're under high load, want that data as soon as possible, and have an ingest pipeline backlog, you won't get the data. So, it's kind of a catch-22.
The Gravwell Approach: We take the data in raw, attach a little metadata, and then put our indexing behind it. That way, if your data changes shape, we don't really care. We can take any type of data. We can take NetFlow. We can take PCAP. We can take binary data. We don't have an ingest pipeline. As soon as it hits the system, it goes to disk, and it's immediately available to search. That’s a fundamental change- the “wow” moment during a demo-though organizations can struggle to get their head around it since it’s such a different approach than what has been done in the past 10- 20 years.
DW: It’s one thing to have the data, collect it, and identify gaps in visibility. But the other side is keeping it running—and that takes time. That presents a question of what you want your security engineers doing, and whether it is high-value or low-value work. You could argue that getting data in is high-value work, but if they don't have to do it in the first place, it quickly becomes low-value work. Instead, organizations could have engineers do other work, like creating new detections and determining if detections are effective or need tuning. Those are all more proactive for security posture.
MW: I like to start thinking about this with the data itself. So, if you are having issues collecting large data sources, specifically things that are binary, PCAP, NetFlow, for example, that come in formats that are not native to text log systems, you're going to have to translate those into something else, into a text format, a syslog or whatever. Then you’re going to lose fidelity. If you translate PCAP into text, you're going to lose something. If you translate NetFlow into text, you'll get a 5x to 7x expansion cost, and you have to search over it.
The Gravwell Approach. We can handle those log types natively. We have search modules that let you decrypt or disassemble them live in the query without converting them to text.
MW: There are philosophical and technical questions you should ask. The philosophical question is whether you can answer questions with the data you have. And that is not just the data sources you have, but also how long you have them. If you have a dwell time of over six months, can you answer a question about that dwell time, that attacker? Then, technically, organizations should ask: if they enable full visibility in NetFlow or DNS, what would happen to their bill? And how much effort does it take to manage their system at large scales? What skills does someone need to administer the system? Is there a large pool of people that could do that?
The Gravwell Approach. One of the biggest things we get asked is around context. How do I get context? How quickly can I get context? What context is there? We have investigative dashboards, which essentially are dashboards where you can input a variable- could be an IP address, could be a username, could be an email. It's entirely custom to an organization, and then it populates a dashboard. They could enter a username, and it can pull in all the relevant identity and access management logs. They might have their EDR logs, Okta logs, or Duo logs all in a single dashboard for a specific user. It gives you that immediate overview, and that's another “wow” moment when people see the platform. The idea that they could just say, "Oh, I can click on this username in my logs and get a dashboard just for that user with all of that visibility across my log sources.” In literally two clicks. In those initial investigations, it just saves so much time and effort. Some tools meant to help detect and investigate threats slow analysts down and limit what they can see right now.
MW: It depends. The last question specifically, people really don't ask because it's kind of an afterthought. But with a lot of our competitors, organizations need very specialized certifications. So, the pool of people that they can get to administer their systems is very small. To make that problem worse, other vendors also hide their training behind expensive classes. Then the pool is even smaller.
DW: A lot of the training that is available is quite sterile. It's on generic points, generic issues. I've spoken to a number of people who've done training that different vendors offer, and they say you've got to be able to extrapolate what they're showing you to what you're seeing day to day.
The Gravwell Approach. We’re 40% to 50% cheaper than our competitors. Our system is built using standard Linux methodologies. We use dot notation for our subdirectories. We use conf files. You can deploy with open-source products. The pool of people we can pull from is much larger than theirs. We can take a basic Linux administrator and get them up to speed on Gravwell in a few minutes. We have this philosophy of wanting people to collect everything and for it to be affordable to do so. We want it to be predictable, and we want them to control their pricing. Those are the three tenets of our broader approach, and they dictate our pricing policy. For a self-managed deployment, we charge customers based on the number of indexers in the cluster. The indexer does the heavy lifting when it comes to searching.
For context, you could have one indexer. We recommend around 300 gigabytes of ingest per day per indexer for optimal performance. But if you spike up to a terabyte a day, the price wouldn't change because the number of indexers hasn't changed. Performance may slow, but that's the point. Can you collect everything? Yes. Is it predictable? Yes, because it hasn't changed, and you control when you add indexers and for how long. Similarly, with a SaaS or cloud deployment, it's basically about how much storage an organization needs. If we're giving you a bucket of storage, how big a bucket do you need? Now the rate at which you fill that bucket up is entirely up to you. If your ingest goes higher or lower, that's fine. We notify you if you're going to fill the bucket faster than expected.
MW: If everything's going right with a company, which you hope it is, they're going to grow. Whatever they budgeted for may not be adequate. If they budget for X amount of Gigs, and then expand 10%, did they have an extra 10% worth of data? Maybe it's exponential; they don’t know. Also, their data will spike in many cases if they are under a DDoS attack, and they probably didn't budget for that. That could hurt their licensing if they go over by a terabyte; then the same day they get a call from their SIEM vendor saying, "Hey, we're shutting you off because you went over.” That’s why it's hard to contain that cost.
DW: 100% of our customers ingest more data than they thought they were going to, and the only variable is by how much more. The average, by the way, is over 100% more. We've had customers who’ve come in and said, "I'm at 100 Gigs a day,” and they end up at 400 Gigs. This is really common. Imagine it's like a police investigation. You want all the possible evidence to help solve the crime. But if you've got more evidence, there's more to search through to get answers to your questions. How effective, though, is a tool at helping you analyze it to get the answers?
The Gravwell Approach. A lot of platforms offer default content. But default content gives you default results, which is the bare minimum. Companies will just sell you the SIEM, give you the default content, and then walk away. Gravwell doesn't do that. We have a whole program around getting an organization into its new platform, into Gravwell, then making it fit like a glove so those investigations are not just default things. We cater to the environment.
MW: This is a common issue with SIEM vendors or with SIEMs in general: if you have to stay under a certain licensing level, then you have to cut logs. And this is no fault of the security engineers. This is no fault of anyone making these choices. This is an “I don't have a choice. I have to cut this data.” So, they cut what they determine is the lowest-value data, like NetFlow, DNS, PCAP, the kind of things that usually get tossed to the wayside.
The Gravwell Approach. There is no ingest pipeline. We just take the data, store it raw, and then there's a pricing model that lets people cut the overall cost of the data they're ingesting while still saving money. They’ve often spent years optimizing their ingest to stay under a limit. The minute that is gone, they can just point all their data at this thing and see what happens. That ability lets them drop data, if needed, from a position of complete visibility rather than partial.
MW: There's a case for sticking with legacy SIEM. It is painful to move things. You're basically doing SIEM archeology to figure out why you have 10 years' worth of searches that Bob wrote, and Bob doesn't work here anymore. It's extremely painful to move.
The Gravwell Approach. We've solved that. We use AI tools. We have mission support. The entire goal is to get an organization from its old system to Gravwell in under 90 days. It’s quick and included in the price. They don’t have to pay extra. That gets people really excited because they can get rid of legacy stuff without having to pick up everything and move it.
There is definitely this impression that “fits like a glove” means expensive, bespoke, boutique. But that is another differentiator of Gravwell. The mission support is included. That's basically the bridge between handcrafted and everything we said about pricing. That flies in the face of what most people think when they say they would love a handcrafted solution but are a small team without a full-time detection engineer. Gravwell gives them the most bang for the buck because they get detections across multiple data sources. They literally click “install” in various apps and get detections across different data sources.
Organizations have shifted how they evaluate SIEM platforms. Rather than measuring success by the amount of data ingested or retained, security leaders should ask whether their platform enables complete visibility, supports rapid investigations, and lets analysts focus on high-value security work instead of maintaining complex infrastructure. Architectural flexibility, simplified operations, and predictable pricing emerge as strategic advantages that can improve both security outcomes and operational efficiency.
Wheatley and Wade also emphasize that many of the costs associated with legacy SIEMs extend beyond licensing. Time spent managing ingest pipelines, limiting data collection to stay within licensing thresholds, maintaining custom integrations, and conducting slower investigations create hidden operational expenses that reduce security teams' effectiveness. Organizations, they say, should seek platforms that remove these constraints, enabling them to collect more data, gain richer investigative context, and scale without adding complexity or unpredictable costs. Ultimately, they reinforce the idea that modern SIEM should enable security operations rather than bottleneck them—allowing organizations to maximize visibility, improve analyst productivity, and make better-informed security decisions.
ABOUT PARTNER INSIGHTS
Partner Insights is a TechChannels sponsored content offering developed in collaboration with TechStudio, bringing technology leaders and industry experts together to share perspectives on the challenges, trends and innovations shaping today’s technology landscape.