| TL;DR: Legacy SIEM architecture has always forced security teams into a losing trade-off. Store more and pay more, or cut back and leave gaps. IBM’s research puts the average breach lifecycle at 241 days, even at its nine-year best. Databricks has been building its answer to that problem: Lakewatch as the open data foundation, and now Panther as the operational layer on top of it. Together, they make the case for a security lakehouse built on open standards, one where teams own their data and aren’t priced out of retaining it. The acquisition is one move in a larger shift: data platform companies are rebuilding security from the ground up, and the SIEM market is starting to feel it. |
In many breaches, the problem isn’t a complete absence of data. The reality is, it’s the difficulty of finding and acting on the right signals quickly enough.
Security operations have a structural problem that’s been hiding in plain sight. Many of the tools most SOC teams rely on weren’t built to handle the volume of data modern threats generate. So teams made compromises: store less, sample more, accept the gaps. And attackers learned to move inside those gaps.
Many legacy Security Information and Event Management (SIEM) architectures were designed when storing and processing large volumes of telemetry was more expensive and technically constrained. Moreover, traditional SIEM economics often force teams to choose between retaining more telemetry at a higher cost and limiting ingestion, risking coverage gaps. Either way, by the time an alert surfaces, analysts may already be moving between disconnected tools trying to reconstruct what happened.
That’s the problem Databricks has been building toward solving, and the acquisition of Panther is simply the clearest signal yet of where it’s headed.
The Trade-Off That Was Never Actually Necessary
The standard SIEM pitch has stayed roughly the same for over a decade. Centralize your logs, set your rules, and get alerted when something looks wrong.
Sounds simple enough. But here’s what that pitch rarely talked about: the cost structure underneath it. Many traditional SIEM products use pricing models tied partly to ingestion volume or retained data, which means security teams end up making a decision that has nothing to do with security: how much telemetry can we afford to keep?
On the surface, it might not seem like a big deal. In practice, though, that cost structure can push teams to filter, tier, or shorten the retention of some telemetry.
IBM’s Cost of a Data Breach Report found that organizations identified and contained a breach within a mean time of 241 days. This is the lowest figure in nine years, yet still nearly eight months of exposure on average. Even at its lowest point in nearly a decade, that’s still a long time for attackers to stay active inside an environment.
You see, cost isn’t the only issue. The other side of the problem is noise. Simply ingesting more telemetry doesn’t automatically improve detection. It can also increase noise when detection logic and prioritization don’t improve with it. Analysts spend time sorting through alert queues instead of investigating the threats that actually matter.
After all, ingestion-based licensing remains an important revenue model for several SIEM vendors, which shapes how the trade-off has historically been managed. And it’s not just a SIEM problem. Obsidian Security’s $85M raise makes the same argument from the identity side: existing tools weren’t built for the speed and scale of how modern threats now move inside enterprise environments.
Why a Data Company Is the One Rebuilding Security
This is where the bigger picture comes into focus. Databricks isn’t primarily a security company. It’s a data and AI platform company that has spent years solving the problem of making petabyte-scale data usable in real time. As it turns out, that’s the exact problem security operations have been struggling with.
Earlier this year, Databricks launched Lakewatch, an agentic SIEM built on top of its data lakehouse. The idea was straightforward: stop treating security data as a separate, expensive silo. Store everything in open formats, run detection and investigation on the same platform, and let AI do the triage work analysts were never meant to do manually.
But Lakewatch was the data foundation. What it didn’t yet have was the operational layer, the mature, battle-tested SOC workflows that enterprise security teams run every day. That’s exactly where Panther fits in.
Panther was designed for modern, cloud-native security operations and positioned itself as an alternative to traditional SIEM workflows. Its core approach is detections-as-code: instead of configuring static rules through a UI, security engineers write, test, and deploy detection logic through standard CI/CD pipelines. Panther’s platform treats threat detection the way a software team treats shipping code, with version control, peer review, and the ability to roll back when something breaks.
It also comes with over 100 pre-built integrations across AWS, Azure, Google Cloud, Okta, and major SaaS applications. More importantly, these aren’t generic connectors; they’re deeply parsed schemas that normalize data before it hits the detection layer.
Together, the combination covers what neither product could do alone. Lakewatch handles the scale and openness of the data layer. Panther handles the workflows, triage, and detection engineering that make that data operationally useful.
The acquisition is how Databricks closes the gap between infrastructure and execution. But the bigger story isn’t the acquisition itself. It’s what it signals: a data platform company has decided the security category is ready to be rebuilt from the data layer up.
Why Open Standards Actually Matter Here
One of the most overlooked parts of this acquisition announcement is the data ownership argument. It’s easy to gloss over, especially with all the attention on AI, but it’s the part that changes the long-term economics for security teams.
Some SIEM platforms rely heavily on proprietary schemas, query languages, or storage layers that can make migration and interoperability more difficult. The result is that moving historical telemetry to another platform can create additional export, transformation, and migration work.
The security lakehouse uses open standards and formats, including the OCSF schema, Delta, and Parquet. OCSF is a schema framework that standardizes how security events are represented. Delta and Parquet handle the storage layer. Taken together, these standards can make the data accessible to a wider range of compatible tools.
Open Cybersecurity Schema Framework (OCSF) is a vendor-neutral open-source framework developed with contributions from across the cybersecurity industry. When Databricks commits to OCSF natively, it’s not just a technical choice. It’s also making a broader statement that it’s building for portability rather than retention.
Databricks says this architecture allows compatible tools to work with the same governed security data, reducing unnecessary duplication. Proprietary storage, schemas, and export processes can add to the cost of changing platforms. That’s exactly the problem the security lakehouse is designed to address. In many ways, this is less a feature decision and more a business model challenge. Openness is how Databricks competes against vendors whose pricing depends on keeping data locked in.
The Agentic SOC Is Not a Feature. It’s a Different Operating Model.
Let’s be honest. The word “agentic” gets used loosely in enterprise software right now. It usually means a chatbot with a few extra steps. But that’s not what Databricks and Panther are describing.
When a threat is detected in the security lakehouse, Databricks says Panther’s AI agents can enrich alerts automatically, correlating cloud logs, identity signals, and business context before an analyst ever opens a ticket. In other words, by the time a human looks at an incident, the investigation has already started.
Why does that matter? Because manual triage consumes time that analysts could otherwise spend on deeper investigations and detection engineering. The goal isn’t to eliminate the analyst. It’s to change what the analyst does, moving from sorting through alert queues to focusing on the edge cases that actually require human judgment.
The detections-as-code model reinforces this shift. Version control and automated testing can make detection rules easier to review, update, and audit as the environment changes. By comparison, static rules configured in a UI can become outdated as the environment shifts.
Taken together, what this points to is a different kind of security team: one that runs more like an engineering organization than an alert-response unit. Ultimately, that’s the organizational shift Databricks is betting on, not just another product capability.
What This Means for the SIEM Market
The broader signal here isn’t just about Databricks. It’s about where the security market is heading.
Databricks argues that the volume and complexity of modern security telemetry have exceeded the architecture of many traditional SIEM deployments. Databricks is betting that its experience with petabyte-scale data infrastructure gives it an advantage in security operations, though established security vendors including Microsoft, Google, IBM, and CrowdStrike also operate large-scale data platforms.
That puts real pressure on traditional SIEM architectures. Enterprise security contracts are long, and switching costs are real. But if the economics of storing and analyzing security data have fundamentally changed, many of the assumptions behind legacy SIEMs may need to change too.
Microsoft has been making a similar case with Sentinel, which runs on Azure’s data infrastructure and positions itself as a cloud-native alternative to legacy SIEM. The pattern becoming visible across the market is this: the companies with the strongest data platforms are moving into security. Not the other way around.
For security teams currently mid-contract with a legacy SIEM, the immediate question isn’t whether to switch. Instead, it’s about asking whether the forced choice between coverage and cost is actually a law of the category. Or whether it’s simply a product decision that can be undone.
Databricks and Panther are betting it is the latter.
