Databricks Buys Panther: Inside the Security Data Lakehouse Shift

Panther is an AI-powered SOC platform built around detection-as-code: security rules are written, tested, versioned, and deployed the way application code is, rather than configured through a SIEM's proprietary rule GUI. It ships with more than 100 pre-built data source integrations across cloud, identity, endpoint, network, and SaaS tools, and it has increasingly leaned into agentic workflows that triage and investigate alerts automatically rather than just routing them to an analyst queue. Notably, Panther had already been running much of its own analysis on Snowflake before this deal, a detail worth sitting with: the acquired company's own architecture choice shows how fluid the underlying lakehouse layer already is in this category.

Databricks frames the acquisition as extending what it calls the security lakehouse category: unifying security, IT, and business data inside a single governed lakehouse, then embedding AI agents directly into detection and response instead of exporting a subset of that data into a separate, closed SIEM data store. CEO Ali Ghodsi put the thesis bluntly: legacy SIEM, in his framing, was never designed for AI. This is Databricks' third security acquisition, following Antimatter and SiftD.ai, and it follows Lakewatch, an agentic SIEM-style platform Databricks introduced in March 2026 to unify security, IT, and business data in one architecture. Panther gives that vision a mature detection-as-code engine and a SOC-analyst-facing product to sit on top of it, rather than requiring Databricks to build one from scratch.

What has not changed yet: the deal has not closed, pricing for a combined Databricks+Panther offering has not been published, and how deeply Panther's product gets absorbed into the Databricks platform versus operated as a semi-standalone layer is still an open integration question, not a settled one.

A traditional SIEM bundles three things that do not have to travel together: a proprietary data store for security telemetry, a detection and correlation engine that runs against that store, and a SOC-facing workflow layer for alerting, case management, and investigation. Bundling made sense when security data lived nowhere else. It stops making obvious sense once the same organization is already running a general-purpose data lakehouse, Databricks or Snowflake, for product analytics, ML, and business reporting, and is paying twice: once to store telemetry in the lakehouse for other purposes, and again to ingest a copy of it into the SIEM's own store to get detection on top of it.

The lakehouse-decoupled architecture separates those layers. Storage lives in a platform you already operate at scale, often already cheaper per terabyte than SIEM-proprietary storage and already retained far longer for other reasons. Detection logic is written as code (queries, rules, or models) that runs against that shared store rather than a walled-off copy of it. The SOC workflow, alerting, triage, case management, sits as a layer on top, which is exactly the product category Panther, Hunters, and Anvilogic all compete in. The pitch is lower duplicate storage cost, one source of truth for both security and non-security data, and detection rules that can be version-controlled, code-reviewed, and tested like any other software artifact instead of configured by hand inside a vendor's rule builder.

The tradeoff is real, not just a footnote for the sales deck. A dedicated SIEM still generally offers a more turnkey out-of-the-box detection content library, a more mature analyst UI purpose-built for security workflows over years of iteration, and a single vendor to call when correlation logic misfires. A lakehouse-based approach asks a security team to either build more of that connective tissue itself, or buy a detection-engineering layer (Panther, Anvilogic, or a native lakehouse offering) to sit on top of storage the team already owns for other reasons. That is a genuine architectural tradeoff between owning more of the stack for less duplicate cost and buying a more complete, if more closed, product.

Databricks+Panther, once the deal closes, points toward a single-vendor architecture: telemetry lands in Delta Lake alongside other workloads, Panther's detection-as-code engine runs against it, and Databricks' broader AI and agent tooling becomes available to the security use case without a separate integration project. That is the tightest coupling of the three approaches and the one most likely to feel like a product rather than an assembled stack, at the cost of being the most exposed to a single vendor's roadmap and pricing decisions once the acquisition is fully integrated.

Snowflake's approach is architecturally the loosest. Snowflake publishes reference architecture (its security data lake solution brief) and prebuilt ML functions for behavior analytics, but it is not itself a SOC product. Snowflake's own positioning treats the data platform as the foundation and expects a partner, historically vendors like Hunters and Panther have both run their products on Snowflake, to supply the detection content, correlation logic, and analyst workflow. That means a Snowflake-anchored security program is really a two-vendor decision: the data platform and whichever detection layer sits on top of it, evaluated somewhat independently.

Anvilogic sits deliberately in between. It does not sell or require its own data store; it is built to run detection-as-code against a customer's existing lakehouse, with named, maintained integrations for both Snowflake and Databricks. For a team that has already standardized on one of those platforms for other reasons and does not want a third-party product dictating where security data lives, Anvilogic's pitch is that the detection layer can be platform-agnostic while the storage decision stays with the customer.

Panther brings more than 100 pre-built source integrations across cloud providers, identity systems, endpoint tools, network telemetry, and SaaS applications, developed independently of Databricks over several years; that library is Panther's most defensible near-term asset regardless of how deeply it gets absorbed into Databricks' own product surface. Databricks separately brings its existing catalog of data connectors and its Unity Catalog governance layer, which the combined offering will presumably lean on for access control across security and non-security data living in the same lakehouse.

Snowflake's own integration surface for security specifically is thinner as a native capability; it is a data platform with a broad general-purpose connector ecosystem (Snowflake Data Exchange, standard ETL/ELT tooling) but relies on partners for security-specific source coverage and detection content, meaning the practical integration story for a Snowflake-anchored program depends heavily on which partner is chosen.

Anvilogic maintains its own integrations independent of the underlying storage layer, plus explicit, named support for building and running on both Snowflake and Databricks, which is the core of its multi-platform pitch: the detection and integration layer travels with the customer's choice of data platform rather than forcing one.

For the layer that actually gets raw telemetry (endpoint, network, cloud, identity logs) filtered, enriched, and routed into any of these platforms in the first place, that is the pipeline-routing problem covered separately in our comparison of Cribl, DataBahn, and Observo AI. These lakehouse and detection-engineering platforms assume that routing problem is already solved upstream; none of the three approaches here replaces a dedicated pipeline tool if log volume and normalization are still unmanaged.

Detection-as-code across all three approaches raises the floor on required skill compared to a SIEM's GUI-driven rule builder. Writing, testing, and version-controlling detections as code is a better fit for teams with at least some data-engineering or software-engineering capacity inside or adjacent to the SOC, and a worse fit for a small team whose detection engineering has historically meant clicking through a vendor's rule wizard.

Databricks+Panther asks a team to operate comfortably in the Databricks ecosystem generally, not just for security, since the value proposition depends on security data actually being unified with other lakehouse workloads rather than siloed in its own workspace. A team with no existing Databricks investment is taking on a full platform adoption, not just a SOC tool swap.

Snowflake-native analytics has the same characteristic in reverse: it assumes existing Snowflake fluency, and the operational burden shifts to evaluating and integrating whichever partner supplies the detection and workflow layer, which is a second vendor relationship and a second set of operational runbooks to maintain.

Anvilogic's pitch is lower switching cost specifically because it does not ask a team to adopt a new data platform at all; the operational lift is learning Anvilogic's detection-authoring model and its AI-assisted rule-building copilot, layered onto infrastructure the team already runs. That is a real advantage for a team that has already made its lakehouse platform decision and does not want that choice re-litigated by a security tool.

None of the three approaches has fully public, apples-to-apples pricing, and none of the specific figures below should be read as a quote a buyer can plan around.

Databricks has not published pricing for a combined Databricks+Panther offering, and the acquisition has not closed. Panther's pre-acquisition pricing model was consumption-based, tied to data ingestion volume, consistent with how most security data platforms price; buyers evaluating this path should request current, deal-specific numbers directly rather than relying on any historical figure, since pricing is one of the first things likely to change once the product is repackaged inside Databricks.

Snowflake's own pricing is standard consumption-based compute and storage pricing, published and calculable through Snowflake's own pricing tools, but that number is only the data-platform half of the cost. Whatever partner supplies the detection and SOC workflow layer prices separately, and that combined total is not something Snowflake itself publishes, since it depends on a third party's contract.

Anvilogic does not publish list pricing; like most enterprise security SaaS in this category, it is quote-based. Buyers should treat every pricing comparison in this space as requiring a direct, current quote rather than a published rate card, and should be skeptical of any third-party estimate, including generalized industry figures, that is not sourced to the vendor directly.

Databricks+Panther's strength is depth of integration once the deal closes: one vendor, one data plane, detection-as-code plus Databricks' AI and agent tooling in a single stack, and a mature 100-plus-integration source library inherited from Panther rather than built from scratch. Its limitation is exactly that depth: it is the most single-vendor-dependent of the three, it requires an existing or planned Databricks investment to make sense, and how the product actually gets packaged, priced, and supported post-acquisition is still unknown, which makes it a harder near-term buying decision than a shipping product would be.

Snowflake-native analytics' strength is flexibility: a team keeps its existing Snowflake investment and chooses a detection and workflow partner independently, which avoids lock-in to a single SOC product. Its limitation is that Snowflake itself is not a complete security answer; the actual SOC-grade detection content, correlation logic, and analyst workflow have to come from somewhere else, which means the real evaluation is really of the partner layered on top, not of Snowflake.

Anvilogic's strength is platform independence: it runs detection-as-code against whichever lakehouse a customer already operates, with named support for both Snowflake and Databricks, so a platform choice made for non-security reasons does not have to be revisited for security. Its limitation is that as an independent, comparatively smaller vendor ($45M in total disclosed Series C funding as of 2024) going up against the R&D budget of the platform owners themselves, its long-term roadmap and integration depth with either Snowflake or Databricks is subject to those larger platforms' own competitive and acquisition decisions, including, directly, the kind of move Databricks just made with Panther.

Databricks+Panther fits a security team inside an organization that has already standardized on Databricks for broader data and AI workloads, where unifying security telemetry with existing lakehouse data is a genuine efficiency gain rather than a new platform to stand up. It is a stronger fit for larger, more data-platform-mature organizations willing to accept single-vendor coupling and to wait for the acquisition's integration roadmap to solidify before committing budget to it.

Snowflake-native analytics fits a team that has already standardized on Snowflake and wants to evaluate the data-platform and SOC-workflow decisions somewhat independently, preserving optionality to swap the detection partner without re-platforming the underlying data store.

Anvilogic fits a team of either Snowflake or Databricks users, of roughly mid-size security operations maturity (enough capacity to engage with detection-as-code, not yet at the scale where building fully custom detection engineering in-house makes sense) that specifically wants to avoid being locked into a single data-platform vendor's own security product, or that is evaluating multiple lakehouse platforms and does not want its security tooling to force that decision prematurely.

For most mid-size security teams without an existing, mature lakehouse investment already running production workloads, a traditional SIEM is still the more defensible default, not a legacy afterthought. Standing up a lakehouse-decoupled detection architecture from zero, choosing a data platform, wiring detection-as-code, building or buying a SOC workflow layer on top, is a multi-quarter architecture project with real engineering dependencies. A team that just needs alerting, correlation, and case management working reliably, without first becoming a data-platform operator, gets there faster and with less risk on a conventional SIEM, even accounting for its higher per-terabyte storage cost.

The lakehouse-decoupled bet makes the most sense when the lakehouse investment already exists for other reasons (product analytics, ML, data warehousing) and security data is a natural, incremental addition to infrastructure the organization is already operating and paying for, not a new platform commitment made solely to serve the SOC. If that precondition is not true today, it is worth revisiting this category again once it is, rather than adopting the architecture ahead of the organizational need.

Before committing budget to any of these three approaches, or to a traditional SIEM instead, validate the following with your own data and your own team, not with vendor-supplied benchmarks: