The CDP market has spent a decade debating where customer data should reside. Databricks has just changed the question. With CustomerLake, the lakehouse-native data platform is not merely storing customer profiles or feeding segments to marketing tools. It claims the marketing workflow itself: identity resolution, audience building, campaign orchestration, decisioning, and activation, all governed within Unity Catalog and powered by agents.
This is not a minor product extension. It is a category move. And it raises a question every CMO, CDO, and MarTech leader should answer: What happens when the platform that already holds your data decides it can also make the decisions?
What Buyers Should Look for in a CDP
Before judging CustomerLake, it helps to reset on what a CDP is actually supposed to do. Vendor messaging tends to blur this, so here are six core capabilities every evaluation should cover.
Data ingestion and integration breadth. A CDP must pull behavioural, transactional, CRM, offline, and third-party data into a unified foundation without requiring every source to be rebuilt. The more formats, APIs, and streaming sources it handles natively, the faster the time to value.
Identity resolution sophistication. Can the platform stitch together anonymous browsing, email addresses, device IDs, loyalty numbers, and offline purchases into coherent individual profiles? The best systems combine deterministic matching, probabilistic modelling, and enrichment from identity partners.
Segmentation and audience building. Marketers need to define, refine, and iterate audiences without filing a ticket every time a new segment is required. Speed, flexibility, and accessibility to non-technical users matter as much as raw power.
Activation channels and real-time capabilities. Profiles are worthless if they cannot be pushed into execution channels quickly. A modern CDP must support marketing automation, advertising platforms, call centres, websites, and mobile apps, ideally with sub-second personalisation where it counts.
Privacy, governance, and compliance. Consent, suppression, opt-outs, audit trails, and data lineage are not nice-to-have features. They are the baseline and universal for any system that touches customer data.
Deployment flexibility. Some organisations want an all-in-one suite. Others want a warehouse-native layer that sits on top of existing cloud infrastructure. The right CDP should match the buyer’s architecture, not force a wholesale migration.
These six dimensions form the lens through which CustomerLake should be judged.
What CustomerLake Actually Does, Capability by Capability
CustomerLake is an Agentic CDP embedded in the Databricks lakehouse. It is currently in private preview, with general availability expected later in 2026. Databricks is positioning it as a marketing application that lives on the lakehouse rather than beside it.
On ingestion and integration, CustomerLake benefits from Databricks’ existing connectors, streaming support, and Lakehouse Federation. Federation is a genuine architectural advantage: it lets teams query trusted data across Snowflake, BigQuery, operational databases, and cloud object storage without copying everything into Databricks. For companies with data spread across platforms, this reduces movement and duplication. The launch ecosystem also includes Adobe, Meta, Acxiom, Epsilon, LiveRamp, The Trade Desk, Braze, Bloomreach, Iterable, Snapchat, Magnite, TransUnion, Adstra, Twilio, IAS, and Unity, which suggests a broad activation map even if real depth remains to be proven.
On identity resolution, CustomerLake introduces Agentic Identity Resolution, combining deterministic matching, probabilistic matching, and agentic workflows for edge cases. It also offers a one-click marketplace for identity providers, including Acxiom, Epsilon, LiveRamp, TransUnion, and Adstra. The promise is that teams can bring their own rules, models, and enrichment partners rather than being locked into a single vendor’s black box. What is unproven is the accuracy and throughput at enterprise scale against established identity vendors.
On segmentation and audience building, CustomerLake uses Genie, Databricks’ natural-language interface, so marketers can describe an audience in plain language instead of SQL. This is a clear bid to make the platform accessible beyond the data team. However, analyst hands-on observations suggest the demo leans heavily on Genie assembling segments automatically, while the full manual GUI exists but is less prominent. Defaults shape behaviour.
On activation, CustomerLake supports reverse ETL and bi-directional pipelines to marketing and advertising tools, plus a Real-Time Profile API for real-time personalisation. Databricks also talks about “Infinity campaigns”: continuous, agent-driven engagement loops rather than static one-off campaigns. This idea is not new to Databricks; several marketing and decisioning vendors have been describing always-on, self-optimising campaigns for years. The practical reality everywhere, including CustomerLake, is still closer to assisted decisioning than fully autonomous marketing.
On privacy and governance, this is where CustomerLake arguably has the strongest claim. Profiles, semantics, and access controls are inherited directly from Unity Catalog. Governance travels with the query, not with a copied data set. Built-in guardrails include opt-out enforcement, suppression for unresolved support tickets, and frequency capping.
On deployment flexibility, CustomerLake is necessarily a Databricks-native play. That is both its strength and its limitation. If the organisation is already committed to Databricks, the fit is natural. If the organisation runs a multi-cloud or multi-platform data estate, the value proposition depends heavily on Lakehouse Federation and on how much marketing workload the business is willing to centre on Databricks.
Pricing is consumption-based, with no separate platform fee for the CDP layer. Databricks monetises through underlying compute and storage. This mirrors the Lakewatch model and represents a structural advantage: a standalone CDP vendor must recover infrastructure and R&D costs from CDP revenue alone, while Databricks can treat CustomerLake as a compute driver for an existing platform.
The Rise of Agentic CDPs
The word “agentic” is becoming unavoidable in MarTech. In the CDP context, it means moving beyond static segments and pre-scheduled campaigns toward systems that continuously observe customer signals, recommend or execute next-best-actions, and learn from outcomes. The ambition is to replace the campaign calendar with a continuous loop.
This shift is not specific to Databricks. Across the industry, vendors are adding agentic layers. Adobe has Agent Orchestrator with purpose-built agents. Salesforce has Agentforce 360. Tealium has a Behavioral Insights Agent. Several other platforms, including warehouse-native activation vendors, are shipping AI decisioning tools. The direction is category-wide.
The underlying cause is simple: the data storage question was largely settled by 2025. Cloud data warehouses and lakehouses became the default foundation. The next competitive battleground is who controls the decisions made on that data. Agents are the interface for that control.
But the gap between vision and reality is wide. True autonomy requires trust, guardrails, explainability, and organisational willingness to let machines make or heavily influence customer-facing decisions. Most deployments today are better described as assisted decisioning: agents propose, humans approve. That is still valuable, but it is not the fully autonomous loop the marketing materials imply.
For buyers, the agentic era means asking harder questions. Which decisions will the system make? Which stay with humans? Where does accountability sit when a campaign agent selects an audience, a channel, and a message? And can the platform explain why a given customer received a given offer?
Head-to-Head: CustomerLake vs Adobe, Salesforce, Segment, and Tealium
Adobe Real-Time CDP remains the safe choice for enterprises already living inside the Adobe Experience Cloud. Its data ingestion and integration strengths are greatest for Adobe-native sources; non-Adobe data often requires more engineering. Identity resolution is mature, with cross-device matching and partner enrichment. Segmentation is powerful but frequently demands specialist expertise. Activation runs natively through Journey Optimizer, making it strongest for organisations that execute within the Adobe stack. Governance is enterprise-grade, though licensing and implementation can be heavy. Deployment is suite-embedded, which delivers coherence but also commits the buyer deeply to Adobe.
Salesforce Data Cloud offers a similar suite-embedded play, with Agentforce 360 adding an agentic layer on top of Data Cloud and Marketing Cloud. Ingestion is deep within the Salesforce ecosystem but weaker outside it. Identity services are strong. Segmentation is integrated with Marketing Cloud and Agentforce. Activation executes natively through Marketing Cloud. Privacy and compliance tooling is robust, though credit-based pricing can be opaque and total cost difficult to model. Like Adobe, it rewards existing commitment and penalises architectural independence.
Segment (Twilio) is still a strong packaged CDP, particularly for developers and real-time event routing. It ingests well through strong SDK coverage and developer-friendly tooling. Identity resolution is good for deterministic stitching, but more limited for advanced probabilistic identity. The audience builder is accessible and built for marketers. Its real strength is activation: it remains a powerful hub for pushing audiences and events to external tools. Native execution is limited, so Segment is better understood as an activation layer than a decisioning platform. Privacy tools are good, but MTU-based pricing can escalate quickly. Deployment is flexible as a standalone packaged CDP.
Tealium offers a practical hybrid path, especially for organisations that want tag management, identity, and audience activation in one place. It inherits strong data-layer DNA from its tag management heritage, which gives it solid ingestion and governance foundations. Identity and enrichment are available through partners. Segmentation is accessible. Activation is primarily audience-focused, with execution handled by partners. Its consent and governance heritage is a genuine differentiator for privacy-conscious buyers. Deployment sits between packaged and warehouse-native, which makes it a good middle ground for teams not ready to commit fully to a lakehouse-centric model.
Databricks CustomerLake differentiates architecturally rather than through interface novelty. Because it sits in the lakehouse, it can claim the freshest data context. Lakehouse Federation reduces the need to copy data across platforms. Unity Catalog provides governance that does not need to be reconstructed by a third party. Identity resolution is flexible through the marketplace, but unproven at scale. Genie makes segmentation more accessible, though the real power users may still be data teams. Activation is broad through partners and reverse ETL, but native execution is thinner than Adobe or Salesforce. Pricing is structurally disruptive. The catch is that these advantages are only fully realised if Databricks is already the centre of gravity for the organisation’s data.
CustomerLake bets on data gravity and architectural openness rather than suite completeness, which sets it apart from Adobe and Salesforce. Segment remains a thinner data platform but a more marketer-friendly interface, while Tealium offers a less ambitious yet proven marketing-specific workflow. The right choice depends less on which product is objectively better and more on where the buyer’s data, talent, and execution already live.
The Critical Lens: Proven, Promise, and What Could Go Wrong
Some things about CustomerLake are already credible. The lakehouse integration is real because it is Databricks building on its own platform. The governance story is strong because Unity Catalog already exists. The pricing model is genuinely disruptive because Databricks does not need the CDP layer itself to be profitable.
Other claims remain promises. There are no published production case studies at launch, only named early customers in implementation. The accuracy of Agentic Identity Resolution at scale has not been independently validated. The depth and reliability of partner integrations under load are unproven. And while Genie is impressive in the demo, marketer adoption beyond power users is an open question.
The biggest tensions are organisational, not technical.
CDP label versus category disruption. Databricks calls CustomerLake a CDP because that is how marketing budgets are recognised, but architecturally, it is trying to make the standalone CDP obsolete.
Data team buyer versus marketing team buyer. CustomerLake will likely be championed by CDOs and data engineers. CMOs may be sceptical of buying marketing workflow from an infrastructure vendor. Databricks’ CMO demonstrated internal use at launch, which was a deliberate signal, but the company still has to learn marketer language.
Assisted versus autonomous. The public demos show human channel selection and campaign duration. “Infinity campaigns” are part of a broader vendor vision for always-on marketing, not a Databricks invention, and the current reality across the market is closer to agent-propose, human-approve than true autonomy.
Embedded versus lock-in. Reducing data duplication is attractive, but it deepens dependence on Databricks.
Pricing asymmetry versus hidden costs. No platform fee is compelling, but compute, storage, engineering headcount, partner licences, and migration costs can still make the total cost of ownership unclear.
Partner ecosystem versus owned experience. Databricks relies on Acxiom for identity, Bloomreach for execution, Braze and Iterable for engagement. A strong ecosystem is also an admission that Databricks does not yet own every layer marketers need.
Who Should Care
CMOs should care because CustomerLake could change who controls the marketing workflow and how quickly it can move. They should also care because adopting it requires trusting a data infrastructure vendor with customer-facing execution.
CDOs and data leaders should care because CustomerLake validates the lakehouse as the foundation for marketing, not just analytics. It may reduce the number of data copies, pipelines, and governance reconciliations the team has to maintain.
MarTech leaders should care because the rebundling cycle is accelerating. The standalone CDP is no longer the only answer, and the composable CDP is being challenged by platforms that own the data layer outright.
Conclusion and Next Steps
CustomerLake is the most serious attempt yet by a data platform to own marketing decisioning. Its advantages are architectural: data context, governance inheritance, federation, and consumption pricing. Its risks are adoption, trust, and the gap between agentic ambition and assisted reality.
For buyers, the next steps are clear.
First, be honest about Databricks commitment. CustomerLake makes most sense when Databricks is already the primary data platform. Second, run a three-year total cost of ownership model that includes compute, storage, engineering headcount, partner licences, and migration effort, not just the headline absence of a platform fee. Third, test marketer adoption early. A technically superior system that only data engineers can operate will not change marketing outcomes. Fourth, define the human-machine boundary clearly. Decide which decisions agents may make, which they may recommend, and where accountability sits.
Databricks has built the data layer marketers need. Whether marketers show up is the question that will decide CustomerLake’s place in the next act of the CDP story.
Leave a Reply