Lakewatch Brings Security to Databricks

Lakewatch turns Databricks from a place where logs are stored into the place where security teams work on those logs. The key advantage is not just a new detection engine, it is that many customers already land application, cloud, and event data in the lakehouse for analytics, so they can run security search, investigation, and AI agents on the same copy instead of building a parallel ingest, storage, and rules stack in a separate SIEM.1 2 3 4

• This follows a broader pattern in data infrastructure where the control point becomes the product. Cribl started by routing and trimming telemetry before Splunk, then moved into search and storage because whoever already sits in the log path can add adjacent security workflow without asking the customer to rewire everything.5 6
• The practical buyer benefit is low change management. In modern data stacks, teams want one governed copy of data and minimal new plumbing. Prior work around Databricks and Unity Catalog shows the same appeal in data security, where products win by enforcing policy and audit directly on the existing platform instead of through a separate proxy or duplicate environment.7
• Incumbents are moving the same way, but from the opposite direction. Microsoft Sentinel now offers its own security data lake with tiered storage and analytics, while Splunk still centers pricing and packaging around ingest and search. Databricks is attacking from the warehouse side, where the logs may already live and where storage economics are already familiar to the buyer.9 10 11

The next step is a rebundling of security analytics into the core data platform. If Databricks can turn existing telemetry customers into Lakewatch users, security becomes another high value workload on the lakehouse, like BI and AI before it, which expands spend per customer and makes the underlying data platform harder to replace.1 2 4 6