Session

From Governed Data to Operational Decisions: A Customer Playbook for Databricks and Palantir

Overview

Experience	In Person
Track	Data Sharing & Collaboration
Industry	Manufacturing, Retail & Consumer Goods
Technologies	AI/BI, Unity Catalog, Databricks Apps
Skill Level	Beginner
DOWNLOAD SESSION SLIDES

In this session, Rich Products shares how we use Databricks and Palantir together to move from governed enterprise data to operational business outcomes. We will walk through the architecture playbook our platform team uses to decide where data lives, where logic runs, and when validated outputs should be written back for broader downstream consumption. As a real example, we will show how we replaced a legacy cost allocation process tied to SAP ECC with a new production workflow that uses Databricks as the governed data foundation, Foundry for allocation logic and operational review, and Databricks again as the publication layer for downstream finance processes. Attendees will leave with a practical framework for balancing speed, scale, and safety across joint-platform solutions without overspecializing to a single use case.

Session Speakers

Ben Abood

/Solutions Architect
Databricks

Brandon Lyles

/Senior Manager
Rich Products

Full Summary

Inside the Databricks and Palantir partnership: a governed operating model from Rich Products

Enterprises increasingly need to extend their lakehouse into operational decision workflows without fragmenting data or governance. The Databricks and Palantir partnership addresses that need by making the platforms composable, so organizations can keep their lakehouse as the governed source of truth while using Palantir for complex, stateful business processes. A real-world operating model from Rich Products shows how to do this at scale on the Databricks Platform, with Unity Catalog as the governance spine. For a broader view of how leading organizations structure this kind of work, the Databricks blog on how to execute your operating model for data and AI captures the strategic principles that underpin composable, governed architectures.

The conversation moves beyond feature checklists. The core idea is a disciplined way to compose platforms: federate data in, push compute to Databricks for writes, publish approved outputs back to Unity Catalog, and make governance executable across the loop. Customers have scaled from dozens to more than 150 joint deployments in a year, with over 100 production use cases and reported efficiency gains of at least 20 percent.

How the platforms interoperate without duplicating data

The integration rests on four product pillars that avoid side-by-side sprawl:

Data federation: Palantir Foundry reads directly from Unity Catalog to power ontologies and applications, so data remains in place at read time rather than being copied.
Governance integration: Workload identity federation and vended credentials allow Foundry workloads to access Databricks APIs and Unity Catalog securely. User identity federation is being scoped to make Unity Catalog the single point of governance.
Compute pushdown: Foundry pipelines and code repositories can invoke Databricks clusters so writes land directly in Unity Catalog using Databricks compute.
AI and workflow integration: Models trained and deployed in Databricks can be registered in Foundry for use in operational applications.

The practical effect is a single governed substrate with minimal duplication, synchronized writes, and clear lineage.

Rich Products' operating model: Databricks first, compose on top

Rich Products adopted a Databricks-first approach for enterprise data, analytics, and AI, extending into Foundry only for complex operational decision workflows that require human judgment, collaboration, stateful drafts, and validated publication steps. The aim was safety, scale, and speed, not tool-by-tool debates.

Six simple principles underpin the playbook:

Go native and prove the exception.
Prefer reusable patterns over one-off projects.
Publish only trusted outputs back to the lakehouse.
Federate into Foundry rather than copying data.
Push compute down to Databricks before considering local execution.
Observe everything, including cost, compute, lineage, and outcomes.

Closing the loop in practice: cost-to-serve allocations

A migration of cost-to-serve allocations off a legacy system pressure-tested the model against complexity and deadlines. Data flowed from ERP systems into Databricks for ingestion, was federated into Foundry for modeling, then underwent human review and validation. Approved outputs were written back to a dedicated write-back catalog in Unity Catalog for broad consumption.

Databricks appeared at three moments in the loop: as the ingestion layer, the governed publication target, and the certified source for downstream analytics, apps, and AI. Consumers inside and outside Databricks accessed approved data products without breaking governance.

What the model prevents and what it enables

The playbook prevented casual data duplication, over-engineering, months-long architectural debates, and platform sprawl. Engineers worked from a clear decision framework rather than relitigating architecture for each new use case.

The model enabled centralized, uniform governance through Unity Catalog across composed workflows, certified outputs that strengthened the lakehouse with each cycle, and faster time to value through repeatable patterns that scale across hundreds of use cases.

Governance as architecture: make the lakehouse stronger every cycle

The goal is not merely connecting platforms. The goal is a governed operating model where every composed workflow federates in, validates, and publishes back, so Unity Catalog remains the spine and the lakehouse grows stronger with each use case. Define the decision framework early, compose on top of Databricks, and encode governance in code and policy.

FAQ

Only when the use case involves complex operational decision workflows that require stateful human review, multi-team collaboration on drafts, and validated publication. Default to Databricks-native patterns, and compose Foundry on top when the business process genuinely calls for it.

Foundry federates Unity Catalog data as virtual tables using vended credentials, with JDBC as a fallback. Reads happen in place. At write time, compute pushdown invokes a Databricks cluster so outputs land directly in a dedicated write-back catalog in Unity Catalog.

All approved outputs, regardless of where they are produced, are published into Unity Catalog under a separate, dedicated catalog from source and curated layers. That keeps lineage, auditability, and access control consistent across composed workflows.

A concise decision framework that states when to stay native, when to compose, how federation and publication work, and how observability will be enforced. Writing this early avoids months of architectural debate and gives engineers repeatable patterns.

Partnership documentation and the Databricks connector are available at palantir.com/partnerships/Databricks. Public blog posts from Palantir and partners describe adoption patterns, and a YouTube walkthrough demonstrates the integration end to end.