---
title: Markin + Databricks
url: https://markin.ai/integrations/databricks
category: Warehouses and lakes
description: Connect Markin to Databricks: read lakehouse tables and feature stores, and write decisions and experiment reads back as Delta tables.
---

# Markin + Databricks

> Lakehouse tables and feature stores as first-class signal.

**Job:** Extend the data science team you already have instead of duplicating it.

A Markin and Databricks setup treats your lakehouse as the substrate: Unity Catalog tables, existing feature stores and model outputs become inputs to the hypothesis space, and Markin writes decisions, holdouts and causal reads back as Delta tables your team can query.

Where a data science team already exists, Markin should extend it rather than duplicate it. Existing features and models become inputs to the hypothesis space instead of being rebuilt.

## What can you ask Markin to do in Databricks?

- How do I operationalise the models my data science team already built?
- Can a decisioning platform read my Databricks feature store?
- How do I go from model score to a measured revenue action?
- What sits between Databricks and my engagement platform?

## What Markin does in Databricks

- Read Delta tables and Unity Catalog assets under your governance.
- Consume existing feature store definitions rather than rebuilding features.
- Take your team's model outputs as one input among several.
- Generate and rank hypotheses across marketing, product, pricing and health.
- Arbitrate competing actions into one decision per customer.
- Write decision and holdout Delta tables.
- Write per-experiment causal reads with confidence intervals.
- Keep every artefact inside your workspace and lineage graph.

## The growth work behind Databricks

### Read the estate

- Read contact history so past sends count as pressure on the customer.
- Track catalogue, pricing and plan changes as they happen.

### Find where revenue is leaking

- Spot pricing and packaging mismatch between what people buy and what they use.
- Spot product friction that correlates with downgrade and cancellation.

### Explain why

- Separate mix effects from real behaviour change.
- Rank drivers by how much of the movement each one accounts for.

### Write hypotheses worth funding

- Attach the evidence and the assumption each one depends on.
- Rank the portfolio by expected value, not by seniority.

### Decide per customer

- Arbitrate between every action competing for that same customer.
- Apply frequency caps, fatigue and quiet hours before anything is committed.

### Execute in the tools you already run

- Write decisions into the CRM, engagement and warehouse systems already in production.
- Trigger journeys and campaigns that your lifecycle team owns and can edit.

### Prove it caused the revenue

- Stop an experiment early when the evidence is conclusive either way.
- Refuse to call a result that has not cleared the evidence standard.

### Retire, govern and hand over

- Retire programmes automatically when they stop beating control.
- Re-test assumptions that decay, such as price sensitivity and seasonality.

Full catalogue: [Everything a growth team does, running every day.](https://markin.ai/growth-work)

## Activation patterns

- **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval.
- **Read only.** Markin reads signal from this system. Nothing is written back and no schema is changed.

## What Markin reads from Databricks

- Delta tables and Unity Catalog assets
- Existing feature store definitions
- Model outputs your team already produces

## What Markin writes back

- Decision and holdout Delta tables
- Per-experiment causal reads

## Used together with

- [snowflake](https://markin.ai/integrations/snowflake)
- [amplitude](https://markin.ai/integrations/amplitude)
- [braze](https://markin.ai/integrations/braze)
- [hightouch](https://markin.ai/integrations/hightouch)
- [optimizely](https://markin.ai/integrations/optimizely)
- [stripe](https://markin.ai/integrations/stripe)

## Related

- [Solution: revenue-expansion](https://markin.ai/solutions/revenue-expansion)
- [Comparison](https://markin.ai/compare/markin-and-your-data-science-team)

## FAQ

**How does Markin connect to Databricks?**

Attribute write-back, Read only. Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval.

**What does Markin read from Databricks?**

Delta tables and Unity Catalog assets; Existing feature store definitions; Model outputs your team already produces.

**What does Markin write back into Databricks?**

Decision and holdout Delta tables Per-experiment causal reads

**Do we have to move our data to Markin?**

No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later.

**Does Markin replace our engagement platform or CDP?**

No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout.

**What if the system we use is not listed?**

The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days.

Source: https://markin.ai/integrations/databricks