Getting Your Security Data Ready for Databricks Lakewatch

Route 320+ Security Sources Into Lakewatch

Databricks is in the security market now. In March 2026, they launched Lakewatch, an agentic SIEM built on the lakehouse: security, IT, and business data unified in one governed environment, stored in open formats, with AI agents automating detection, triage, and hunting. The economic pitch is a direct shot at ingest-based SIEM pricing. Costs track the work the platform performs, not the volume you send it, so the 75% of telemetry that teams currently drop to control SIEM bills can stay. Adobe and Dropbox are among the early customers, and Lakewatch is available in private preview.

Lakewatch handles what happens once data is in the lakehouse: detection, triage, hunting, response. Monad, a Databricks Brickbuilder partner validated at the Bronze tier with Connected status, handles the part before that. Our job is the unglamorous one: getting your security data into the lakehouse so everything Lakewatch does has something to work with.

The part of the migration nobody budgets for

For teams evaluating Lakewatch, the hardest part isn't choosing the destination. It's replicating the data feeds your legacy SIEM had out of the box.

Any team that's migrated off a SIEM knows this firsthand. The old platform had pre-built integrations for every source. Moving means rebuilding those feeds across 50, 100, or 200 security tools, and security telemetry is a different animal than general-purpose data. The APIs are unstable. Vendors ship breaking changes without notice. Schemas vary wildly across tools, and even across versions of the same tool. Rebuilding that by hand is weeks or months of engineering before the new platform has enough data to prove anything.

And raw data isn't enough. JSON dumped into lakehouse tables as-is creates a second problem downstream: analysts writing ad hoc parsers in notebooks instead of running detections.

Where Monad fits

Monad connects 320+ security sources, including the on-prem infrastructure that cloud-only collectors can't reach, and streams them into the lakehouse through our Databricks Lakehouse connector. Ingestion runs through Autoloader or ZeroBus depending on how you run Databricks; the trade-offs between the two are covered in [our partnership announcement](TK: partner blog link). Every connector is tested daily against live APIs, so when an upstream vendor changes an authentication flow or a response schema, we catch it before your pipeline breaks quietly.

On the way in, Monad can normalize data to OCSF before it lands in the Unity Catalog-governed tables Lakewatch works from. That means consistent field names across sources on arrival: Okta events and CloudTrail events that already line up, instead of a translation layer someone has to build and maintain downstream. You can also enrich events in flight with threat intel, asset context, or identity data, so the context is in the row before anything queries it.

Run both, then shift

SIEM migrations don't happen in a single cutover, and Lakewatch's private preview status makes the parallel-run question concrete rather than theoretical. Monad routes the same data to multiple destinations simultaneously: keep your existing SIEM fed while your lakehouse fills, build confidence in the new environment on complete data, then shift traffic source by source as you're ready. No duplicate pipelines to maintain, and no visibility gap in the middle of the transition.

Start before you have access

Lakewatch is in private preview, which makes this the useful window. The teams that will get value from it fastest are the ones whose telemetry is already landing in the lakehouse, normalized and complete, on the day they get access. The ingestion buildout is the long pole, and it's the part you can start now.

If you're evaluating Lakewatch or already running security workloads on Databricks, schedule a demo and we'll show you your own sources landing in the lakehouse. Bring the one that's been hardest to wire up.

‍