# Databricks CustomerLake: a customer data platform inside the lakehouse

> CustomerLake builds Customer 360 profiles and audiences on data already in Databricks. What's in Beta, and the workloads we'd move to it first.

Published: 2026-10-26
Author: Preetham Reddy
Tags: Databricks, AI/ML, Knowledge Share
Canonical: https://www.techfabric.com/blog/databricks-customerlake-a-customer-data-platform-inside-the-lakehouse

---

When the Texas Rangers moved their streaming to BZZR in July 2026, part-way through the season, the existing subscribers came across into BZZR accounts without being asked to sign up again. Our engineers built that platform through to production, with click analytics running on Databricks, and the work in front of it now is joining what each viewer watched to the content graph, so a club can be told what its audience also follows ([case study](/case-studies/bzzr)).

A retailer or a lender has its own version of that job. The orders, app events, support tickets and model scores are often in the lakehouse already, and the marketing team still waits for a copy of them to land in a separate customer data platform before it can build an audience. Databricks announced CustomerLake on 16 June to remove that copy. It's an agentic customer data platform that runs inside Databricks under Unity Catalog, and on 19 October its Campaign Agents moved to Beta and its Profile Agents to Private Preview ([Databricks](https://www.databricks.com/blog/customerlake-beta)).

We haven't run CustomerLake on a client workload yet.

We do build the lakehouse it sits on, and whether it's worth a team's first quarter comes down to how much of its customer data is already governed there.

## What CustomerLake does inside Databricks

CustomerLake is two sets of agents that work on data already in a Databricks workspace, and a team can adopt either one without the other.

Profile Agents build the Customer 360. They map fields from different sources into one structure, resolve identity by combining deterministic rules with probabilistic and LLM-based matching, and apply survivorship rules to decide which value a golden record keeps. Profiles update incrementally in micro-batches, and a data steward can override a match. Databricks says teams can bring their own identity rules, models and enrichment partners, which matters to anyone who already has a matching process they trust.

Campaign Agents work from those profiles. They build audiences, recommend a next-best action, push audiences to the channels marketing already uses and adjust against a business goal. Audiences can be described in plain language through Genie, which is how a CRM team gets one without filing a ticket with data engineering. Databricks calls the always-on version "infinity campaigns", and its Beta post describes them as where the product is heading.

All of it starts from the orders, app events, ERP and CRM records a company has already landed as governed tables in Unity Catalog. Two parts of the platform carry the rest. Lakehouse Federation lets CustomerLake read customer data where it sits, in Snowflake, BigQuery, cloud storage or an operational database, without copying it first. We used Federation as the first step when we moved a B2B product's client reporting onto Databricks ([part 1](/blog/embedded-analytics-on-databricks-part-1)). Reverse ETL and native integrations send audiences out to tools such as Braze, Salesforce Marketing Cloud, Adobe, Meta and The Trade Desk, and bring engagement data back.

```mermaid
%% caption: Profiles and audiences are built on the governed tables, and engagement from each channel comes back to the same tables.
flowchart TD
  A["Orders, app events, ERP and CRM records"] --> B["Governed tables in Unity Catalog"]
  F["Snowflake, BigQuery, an operational database"] -->|"Lakehouse Federation"| B
  B --> C["Profile Agents: identity resolution and golden records"]
  C --> D["Campaign Agents and Genie: audiences and next-best action"]
  D -->|"Reverse ETL"| E["Braze, Salesforce Marketing Cloud, The Trade Desk"]
  E -->|"Engagement data"| B
  class D accent
```

## Why a CDP inside the lakehouse changes the decision

A standalone CDP holds a second copy of your customers. Every attribute marketing wants has to be piped into it, the pipeline breaks when a source schema changes, and the CDP's view of a customer drifts from the one finance and product report on. Access rules get written twice, once for the warehouse and once for the CDP, and a privacy request has two places to reach.

CustomerLake works on the copy you already govern. Its agents run under Unity Catalog permissions and audit logging, so the access rules a data team maintains today are the ones an audience is built under. Getnet by Santander built its first Customer 360 on it with churn propensity scores beside transactions and behaviour, according to Databricks. A model trained in Databricks is already a table there, so its score reaches an audience without an export job.

Pricing follows a consumption model, and Databricks hasn't published prices. For a buyer, the cost question moves from a licence per seat or per profile to how much compute the agents use, and nobody can quote that until Beta workloads show it.

The Beta post carries customer-reported results. The Philadelphia Union replaced its previous CDP and cut audience turnaround by 90%, and Wine.com launched production email campaigns 23 days after kickoff, with 100 audiences syncing daily to Braze across 6.5 million profiles. They're the vendor's figures, with no method published, and both describe the work we'd expect to move first, which is audience building that used to wait on an engineer.

## Workloads CustomerLake makes practical

| Workload | What it needs in the lakehouse | Agents | Status on 26 October 2026 |
| --- | --- | --- | --- |
| Customer 360 without a CDP copy | Customer, order and event tables with keys that join a person across systems | Profile Agents | Private Preview |
| Self-serve audiences for CRM teams | Resolved profiles and the attributes marketing is allowed to see | Campaign Agents with Genie | Beta |
| Propensity-driven campaigns (churn, cross-sell, next purchase) | Model scores published as governed tables | Campaign Agents | Beta |
| Activation to email, push and paid media | Destination connections and consent flags | Campaign Agents with reverse ETL | Beta |

A regional lender could feed servicing records, app logins and a refinance-propensity score into Profile Agents, then have the servicing team ask Genie for borrowers whose rate sits two points above today's offer and who haven't logged in for 60 days. That list could reach the lender's email platform the same afternoon. The measure we'd hold it to is the time from question to live audience, against what the lender's data team takes today.

A distributor running Dynamics 365 Business Central keeps its order history in the ERP, and that history is where its customer value sits. Once those orders land in Unity Catalog beside ecommerce sessions, a Campaign Agent could find accounts whose reorder interval has slipped and route them to the sales team or an email sequence. For most Business Central companies, landing the ERP data governed is the project we'd start with, before any agent.

We moved DealerIQ's TotalLoop, the platform that matches a dealership's customers who have equity in their vehicle to cars on the lot, onto Lakebase ([case study](/case-studies/dealeriq)).

A match like that is an audience.

A dealer group with equity matches in Databricks could hand them to Campaign Agents, choose the channel per customer and send the replies back as engagement data for the next round of matching.

## Where CustomerLake stops today

- Profile Agents are in Private Preview, so the identity resolution half is the harder half to get. A team that needs Customer 360 first could run Campaign Agents on profiles it already resolves while it waits.
- Databricks hasn't published the Beta's technical requirements, a general availability date or prices. Access goes through a Databricks account team.
- Every published result describes daily syncs, monthly sync counts or micro-batch profile updates. None shows a decision made inside a live web session, so a team whose case is personalisation on page load should test that before retiring anything.
- It assumes the customer data is in Databricks or reachable through Federation. A company whose customer data lives only in a SaaS CDP has the lakehouse to build first.
- Marketers gain self-service, and the data team gains control over what they can see. David Raab of the CDP Institute put it plainly to CMSWire: "IT gains more control, which marketers may not appreciate." Agreeing who owns which attributes is part of the project.

## How we'd start a CustomerLake project

We'd begin before the Beta conversation, with an inventory of where customer data sits: which tables are in Unity Catalog with owners and tags, which keys join a person across systems, and where consent is recorded. If the consent flag exists only in the email platform, an audience built in Databricks can't honour it, and that's the first thing to fix.

Then one audience. We'd pick the one the marketing team waits longest for, build it on Campaign Agents with the identity resolution the company already trusts, and run it beside the current CDP for a month. The numbers we'd compare are the time from request to live audience, the match rate against the old tool and the compute it used. Profile Agents would come next, tested against the incumbent matching on a sample where the right answer is known.

The agents need the same limits we'd put on any agent that acts for a company: which audiences it may send without a person approving, to which channels, and what it logs. We set out the limits we use on our own agents in [Governing AI agents with Databricks and Temporal](/blog/govern-ai-agents-databricks-temporal), and they carry over to an agent that sends email.

If your customer data is already in Databricks, start by counting how many of marketing's last ten audience requests needed an engineer. Those requests are the ones we'd move to CustomerLake first.

## Frequently asked questions

### Is Databricks CustomerLake generally available?

No. Campaign Agents entered Beta on 19 October 2026 and Profile Agents entered Private Preview the same day. Databricks hasn't announced a general availability date or prices, and access goes through your Databricks account team, subject to technical requirements it hasn't published.

### Does CustomerLake replace our existing CDP?

It can, for a company whose customer data is already in Databricks, and the Philadelphia Union replaced its previous CDP with it, according to Databricks. Whether yours should go depends on what it does that CustomerLake doesn't yet, real-time decisioning in particular, and on when its contract renews. We'd run one audience on both before deciding.

### Do we need to move all our data into Databricks first?

No. Lakehouse Federation lets CustomerLake read customer data in Snowflake, BigQuery, cloud storage and operational databases where it sits. The governance and identity work still happens in Unity Catalog, so the tables it reads need owners, permissions and keys that join a customer across systems.

### Can marketers use it without the data team?

For building audiences, yes. Genie lets them describe an audience in plain language, and Databricks reports that Zé Delivery's CRM team syncs audiences to Braze without engineering support. The data team still decides which tables and attributes are exposed and under what permissions, and that setup comes first.

### How is CustomerLake priced?

Databricks says it uses a consumption model rather than a traditional software licence, and it hasn't published prices. Cost will follow how much the agents run, so we'd measure the compute behind one audience during the Beta before estimating a full rollout.

## Sources

- Databricks, [Introducing CustomerLake: the agentic CDP embedded in Databricks](https://www.databricks.com/blog/introducing-customerlake-agentic-cdp), 16 June 2026
- Databricks, [CustomerLake enters Beta](https://www.databricks.com/blog/customerlake-beta), 19 October 2026
- CMSWire, [Databricks CustomerLake enters Beta as enterprises go live with agentic CDP](https://www.cmswire.com/customer-data-platforms/databricks-customerlake-enters-beta-as-enterprises-go-live-with-agentic-cdp/)