I’ve been evaluating platforms that promise to handle both infrastructure/operational logs and security telemetry in a single pane, and Devo keeps coming up in conversations. The sales pitch is compelling—a unified data pipeline, one query language, one cost structure. But in practice, I’ve seen other platforms buckle under the tension between these two use cases. The schemas get messy, the performance for real-time detections suffers, and the teams end up fighting over resource allocation.
I’m reaching out to this community because I’d love to hear from anyone who has actually gone down this path with Devo in production. I’m particularly concerned with the practical, day-to-day realities of such a deployment. My specific questions are:
* **Schema and Onboarding:** Did you maintain separate domains/applications for infra vs. security, or did you blend everything into a common event structure? How did you handle conflicting field names or different parsing needs?
* **Performance and Cost:** Did you run into issues where high-volume, low-value infra logs (like verbose debug or application logs) impacted the ingestion or query performance for your critical security events? How did you manage ingestion quotas and cost control between the two competing stakeholders?
* **Team Workflow:** How did you handle access controls and visibility? Could your security analysts write detections without being overwhelmed by operational data fields? Conversely, could your platform engineers troubleshoot effectively without seeing security-specific enrichments?
* **Vendor Relationship:** Was Devo’s support and professional services team adept at navigating these cross-functional requirements, or did they lean towards treating it as a security-only tool?
I’m less interested in the theoretical and more in the gritty details. For context, we’re looking at several hundred GB per day, with a roughly 60/40 split between infra/ops and security data. Any insights on how you structured the contracts, the SLAs, or even the internal chargeback model would be incredibly valuable.
— frank
buyer beware, but buy smart
It's a smart set of questions, because that tension is real. My experience with Devo in this setup has been positive, but it required upfront planning that the sales pitch doesn't always emphasize.
You asked about schemas and onboarding. We did maintain separate logical domains for infra and security within the same platform. The key was using Devo's application tagging and table structure from day one to enforce a separation, even though the data flows through the same pipeline. This let us apply different parsing rules and retention policies per domain without conflict. So the fields could be named the same in different contexts, and it wasn't a problem because queries were always scoped to a specific application context.
On performance and cost, that's where your governance needs to be sharp. High-volume, low-value logs absolutely can drown out security events if you let everything into the same tables without filters. We solved this by implementing aggressive filtering and sampling at the ingestion level for verbose operational logs before they ever hit the platform. This kept our security event ingestion performance stable and costs predictable. The teams didn't fight over resources because the allocation was decided and automated in the ingestion rules, not negotiated after the fact.
Keep it civil, keep it real
Totally agree on the aggressive filtering from day one, that's the only way to keep the cost monster in its cage. We learned that the hard way after letting our network gear just blast raw syslogs into the platform for a month. Our bill looked like a phone number, and SecOps couldn't find a dang thing in the noise.
One thing I'd add to your point about governance is that you've gotta get both teams to agree on what "low value" operational logs actually are. Our infra team fought us tooth and nail on sampling their precious debug logs until we built a side-channel "safety net" bucket with a 30-day retention just for them. It kept the peace and let us filter the main pipeline way down. Without that compromise, the resource fights would've killed the project.
You're right to be cautious about the single-pane promise. The unified pipeline is achievable, but only if you treat it as a technical fact, not an organizational one. Teams should absolutely maintain separate ownership over their own data domains, table schemas, and dashboards within the platform.
The most common pitfall I've seen is when one team tries to "standardize" the event schema for everyone in a well-intentioned but misguided push for uniformity. That's what creates the real mess. Let security parse their Zeek logs their way, and let infra have their own schema for Apache access logs. Devo can handle that divergence as long as you use application context properly from the start.
It's less about blending data and more about building clear, agreed-upon lanes on the same highway.
Stay constructive
Oh, the "clear lanes on the same highway" analogy is so dangerously optimistic, though. It assumes everyone obeys the traffic laws. In my experience, building those lanes just creates a bureaucratic speed limit for the team that actually needs to move fast, usually security.
You let infra have their own schema for Apache logs, and soon enough you've got five different versions of `client_ip` because three different SREs built their own parsers on three different Tuesdays. When a zero-day drops and you're trying to correlate IOCs across those "separate domains," you're suddenly in a data mapping hell the sales deck never mentioned. The platform can technically handle the divergence, but your SOC analysts can't, not at 2 AM.
The push for uniformity isn't always misguided, it's often a desperate reaction to the chaos of total freedom. Maybe the mess isn't the standardized schema, but the Wild West you get without one.
Price ≠ value.