Monad + Databricks Brings 300+ Security Sources Into Lakehouse

Monad is now a Databricks Brickbuilder partner, validated at the Bronze tier with Connected status. The partnership brings Monad's 300+ security sources to the lakehouse: our new Databricks Lakehouse connector lands data in your Delta tables through two distinct ingestion patterns, so you pick the one that matches how you run Databricks instead of bending your architecture around the pipe.

The problem this solves is one you already own if you run security workloads on Databricks. Every log source that matters, identity, endpoint, cloud audit, SaaS, network, needs a path into the lakehouse, and that path is usually a custom Spark job, a staging bucket someone maintains by hand, or a notebook parser that breaks the next time a vendor changes their API response. The lakehouse is a great place for security data. Getting it there reliably is the part nobody wants to own.

Here's how each pattern works and when to use it.

Autoloader: file-based ingestion, managed by Monad or by you

Monad stages gzip-compressed JSONL files to a Unity Catalog Volume, batched for throughput at up to 50,000 records or 20 MB per staged file. From there, an Autoloader (cloudFiles) job picks the files up and handles ingestion, scheduling, and schema evolution the Databricks-native way.

The new part is who sets that job up. You choose: Monad can create and schedule the Autoloader job for you, or your team configures and runs its own cloudFiles job against the volume path. If you already manage ingestion pipelines in Databricks and have opinions about how schema evolution should work, keep the job in your hands and Monad stays a delivery layer. If you don't want to own another pipeline, hand the whole thing to Monad. Either way, no SQL warehouse is involved, and Monad creates the volume if it doesn't already exist.

ZeroBus: direct streaming, no staging

ZeroBus is the low-latency option. Records stream directly into an existing Delta table over the Databricks ZeroBus protocol. There's no volume staging and no SQL warehouse in the path at all. Configuration is three fields: workspace ID, region, and table name. Monad builds the endpoint from there.

The constraint is that ZeroBus writes into a fixed schema. The target table must already exist, and Monad won't create it or evolve its schema in this mode. The required table privileges are encoded into the OAuth token itself, so your service principal needs SELECT and MODIFY on the table before the first record flows. In exchange, you get streaming ingestion into your lakehouse without paying for warehouse compute or managing an ingestion job.

Picking a pattern

Both patterns authenticate with OAuth M2M service principals, and both validate setup during Test Connection. If a grant is missing, you find out before data flows, not after, and the test tells you which specific permission to fix.

The data is better before it lands

Delivery is only part of what the pipeline does. Because Monad sits between your sources and Databricks, everything in the platform applies before data hits your tables.

You can filter out low-value events so your Delta tables hold signal instead of bloat, and route a full-fidelity copy to object storage if compliance requires complete records. You can enrich events in flight with threat intel, asset context, or identity data, so the context is already in the row when a query runs. And Monad can normalize data to consistent schemas, including OCSF, before it lands, which means consistent field names across sources instead of a translation layer in every notebook.

Rubrik runs security data into Databricks through Monad today.

See it running

If you're building security workloads on Databricks, or moving them there, schedule a demo and we'll show you all three ingestion patterns against your actual sources. Bring the log source that's been hardest to land and we'll start with that one.

‍