How do you build a real data product in Databricks?

Do you now have a data product?

Maybe.

But not because of that.

Databricks today ships a surprisingly large number of the building blocks you need for a good data product: central governance via Unity Catalog, automatic lineage tracking, Lakeflow for declarative pipelines, Quality Expectations, Metric Views for business semantics, governed tags, attribute-based access control, system tables for observability, and Delta Sharing or Marketplace for distribution. (Databricks Docs)

That's a lot.

But the platform still doesn't answer the most important question for you:

That's exactly where I'd start – and it's exactly where the conceptual article A data product is not a dataset with an owner begins as well.

Because if you look at a data product in Databricks purely from a technical perspective, you might end up with an excellently governed table.

But not yet a product.

Don't start with catalog and schema

When teams talk about data products in Databricks, the discussion often starts roughly like this:

These are important questions.

But they come too early.

Before you fix the Unity Catalog structure, you should define something else:

Let's take an example.

A company wants to build a data product called:

A bad definition would be:

That describes the processing.

A better definition would be:

Now we can make architecture decisions.

Because suddenly we know:

Who consumes the product?

Marketing and Customer Management.

What's its purpose?

Customer segmentation and customer steering.

Which central business terms do we need?

Active customer.

Revenue.

Customer value.

Purchase history.

What freshness is required?

Maybe four hours.

Maybe daily.

Which quality errors would be critical?

Missing customer IDs are probably very critical.

A missing marketing classification, perhaps less so.

And who's allowed to use the product?

Not necessarily everyone who has access to the underlying CRM data.

These questions define your product – the same product thinking behind Data Mesh.

Databricks then helps you technically enforce this promise.

Not the other way around.

The data product is not a table

This is especially important in Databricks.

A data product can technically consist of multiple objects:

The table is an important part of that.

But the actual data product is the entire consumable interface.

For a data scientist, that might be a curated Delta table.

For a business user, a Metric View.

For an application, a view or a shared table.

For an external partner, a dataset provided via Delta Sharing.

For an AI agent, a Metric View with cleanly defined fields, measures, synonyms, and agent metadata can be the more sensible interface – exactly the point where Genie Ontology and Unity Catalog Semantics come in.

That's why I'd make one important architectural decision:

Model your data product logically – and let Databricks objects implement individual product capabilities.

Not:

But rather:

That sounds like a small difference.

On larger platforms, it's a decisive one.

Unity Catalog is the backbone – not the product

Unity Catalog is today the central governance layer for data and AI in Databricks. Access control, lineage, auditing, and discovery are brought together there across workspaces. (Databricks Docs)

That's an excellent foundation for data products.

But Unity Catalog first and foremost describes which assets exist and how they're controlled.

It doesn't automatically tell you which assets together form a business product.

That's why I'd deliberately use Unity Catalog as a product governance layer.

For example:

customer_domain
│
└── customer_value
    │
    ├── customer
    ├── customer_orders
    ├── customer_value_daily
    ├── customer_value_metrics
    └── customer_segments

Whether customer_domain is a catalog and customer_value is a schema depends on your governance structure.

Databricks explicitly describes catalogs as the top-level unit of organization in Unity Catalog and recommends structuring them by logical data isolation and access boundaries. So a catalog isn't, by definition, a domain, nor is it, by definition, a data product. (Databricks Docs)

That matters.

That's why I wouldn't set up a rule like:

Or:

Rules like these look tidy in architecture diagrams.

But they only work as long as your security, ownership, and organizational boundaries happen to align exactly with that structure – a pattern that also shows up in the article on the SAP Unity Catalog admin hierarchy.

A better question is:

If a domain has its own access rules and administrative responsibilities, a catalog can make sense.

If several products share the same governance boundaries, schemas can be the better product layer.

The Unity Catalog hierarchy should follow your governance.

Not your wish for a tidy namespace.

A possible target picture

I'd break a larger data product down roughly like this:

catalog
└── customer
    │
    ├── raw_internal
    │
    ├── curated
    │   ├── customers
    │   ├── orders
    │   └── customer_value
    │
    ├── products
    │   ├── customer_value_current
    │   └── customer_value_metrics
    │
    └── restricted

The important part here:

raw_internal is not a data product.

curated isn't automatically one either.

Only under products do you find deliberately designed consumer interfaces.

This prevents a common confusion:

Medallion layers are processing layers. Data products are consumer interfaces.

Bronze, Silver, and Gold can help you structure the data technically.

But a Gold table doesn't become a data product just because it's called Gold.

Step 1: Build the physical truth cleanly

Before we can talk about semantics, we need a technical foundation we can trust.

Lakeflow Spark Declarative Pipelines is today a central Databricks building block for this. Lakeflow can declaratively express batch and streaming pipelines in SQL or Python and handles, among other things, orchestration and incremental processing. The tables managed by pipelines are Delta tables. (Databricks Docs)

For our example, the pipeline might integrate data from CRM, ERP, and the webshop:

CRM Customer
        \
ERP Customer -----> Customer Resolution
        /                  |
Webshop                    v
                     customer_master
                           |
Orders --------------------+
                           |
                           v
                  customer_value_daily

The goal of this layer is not yet:

But rather:

That includes:

Only once this foundation is stable is it worth building a product promise on top of it – and connecting sources so that decisions become resilient, not just tables full of data. This is exactly what the hybrid business analytics platform addresses, as does the question of when a hybrid data platform becomes expensive without decision logic.

Step 2: Quality belongs in the pipeline – but not only there

Lakeflow supports what are called Expectations.

An Expectation is a declarative quality condition that validates records. Depending on configuration, violations can be observed, the corresponding records dropped, or pipeline updates aborted. (Databricks Docs)

For example:

CONSTRAINT valid_customer
EXPECT (customer_id IS NOT NULL)
ON VIOLATION FAIL UPDATE

Or:

CONSTRAINT positive_revenue
EXPECT (annual_revenue >= 0)
ON VIOLATION DROP ROW

Since 2026, Databricks has further expanded this capability. Quality Expectations can now also be applied to standalone materialized views; Databricks has additionally introduced functionality to manage Quality Expectations centrally alongside Unity Catalog tables. (Databricks Docs)

This is interesting for data products.

Because it turns:

into a technical guarantee.

Still, I'd avoid one mistake:

A data quality rule is not the same as a product SLA.

Technically, 99.99 percent of all customer IDs might be present.

If the data arrives two days late, the product is still worthless for a given use case.

That's why I'd separate technical Quality Expectations from business Product Expectations.

For example:

Technical Quality
├── customer_id NOT NULL
├── revenue >= 0
└── valid country_code

Product Expectations
├── Freshness < 4h
├── Completeness > 99.5%
├── Customer reconciliation completed
└── Critical incidents acknowledged < 30 min

Databricks can measure and operationalize a lot of this.

But the acceptable thresholds must come from the product context.

Step 3: Don't document the table. Document the meaning.

A table can be perfectly documented and still hard to understand.

Take this:

customer_id
customer_status
net_sales
value_segment
effective_date

Technically, that sounds usable.

But:

Databricks supports comments on Unity Catalog assets and individual columns. Comments improve discovery and can be made visible via BROWSE without the user automatically getting access to the data itself. (Databricks Docs)

Databricks also offers AI-generated comments.

That's convenient.

But Databricks itself warns against adopting AI-generated descriptions as truth without review. The suggestions are generated from metadata such as schema and column names and are meant to be reviewed by a human before saving. (Databricks Docs)

This is exactly where I'd be strict for data products – the same boundary as in Evidence-first AI: the model may suggest. It may not determine what's binding within the company.

An AI-generated text might write:

Your data product needs to know:

That's the difference between documentation and semantics – and the reason meaning belongs in the context layer, not in the prompt.

Step 4: Extract business semantics from individual tables

And this is where Databricks gets especially interesting in 2026.

Metric Views have become a central implementation layer for business semantics in Unity Catalog.

They let you define business measures centrally and manage them separately from the dimensions used to group or filter them. (Databricks Docs)

This is a significant step forward for data products.

Because instead of:

Table A:
annual_revenue

Dashboard B:
SUM(invoice_amount - returns)

Dashboard C:
SUM(net_amount)

Genie:
interprets revenue on its own

the product can provide a single, central business definition.

For example:

Customer Value Metric View

Dimensions
├── Customer
├── Country
├── Segment
├── Month
└── Product Group

Measures
├── Net Revenue
├── Customer Count
├── Revenue per Customer
└── 12M Customer Value

Metric Views now support not just measures and dimensions, but also joins, filters, more complex measures, and metadata for AI agents. Databricks names, among other things, synonyms, display names, and formatting rules intended to improve interpretation by agents. (Databricks Docs)

This creates something quite interesting:

A data product's business interface no longer has to be identical to its physical table.

That's exactly what I want – and what we classify, in Genie Ontology and Unity Catalog Semantics, as the platform-level implementation of the context layer.

The Delta tables represent the physical data foundation.

The Metric View represents part of the business meaning.

The consumer doesn't just get:

But rather:

For analytics and AI, that's considerably more valuable.

Step 5: Don't use tags as decoration

Tags in Unity Catalog can organize assets and support discovery.

With governed tags, organizations can additionally define controlled, account-wide tag vocabularies. Databricks now also supports system tags; certain system tags can, for example, mark assets as certified or deprecated. (Databricks Docs)

This lets you build real product governance.

For example:

domain = customer
product = customer_value
lifecycle = production
criticality = tier_1
classification = internal

And additionally:

Certified

for the official consumer interface.

Or later:

Deprecated

once a product is replaced.

That sounds trivial.

It isn't.

Because in many platforms, the following exist simultaneously:

customer_value
customer_value_v2
customer_value_new
customer_value_final
customer_value_final2
customer_value_2025
customer_value_use_this

The real problem here isn't data discovery.

The problem is:

No one knows which asset is authoritative.

A data product should answer this question explicitly.

Not through convention.

Through metadata and governance.

Step 6: Separate ownership technically and organizationally

Unity Catalog has a clear ownership model.

Every securable object has an owner. The owner holds far-reaching rights over that object and can manage privileges or transfer ownership. For production assets, Databricks explicitly recommends assigning ownership to groups rather than individual people. (Databricks Docs)

That makes sense.

But:

Unity Catalog ownership is not automatically product ownership.

A group like

grp_customer_data_admin

can technically be the owner of a schema.

The business data product owner could nonetheless be a specific role within the customer domain.

These two responsibilities should be deliberately linked.

For example:

Business Product Owner
Roman / Customer Analytics
        |
        | Product decisions
        v
Customer Value Data Product
        ^
        | Technical administration
        |
Unity Catalog Owner
grp_customer_data_product_admin

Why separate them?

Because the business product owner may need to decide:

Whereas the Unity Catalog owner decides:

Both are ownership.

But not the same kind.

If you don't separate them, business decisions often end up with platform admins.

And technical permission decisions end up with business units.

Neither is a particularly good idea.

In decision architecture, it's the same distinction: ownership without decision authority just becomes escalation. This is exactly what the Ownership Blueprint addresses – and, organizationally, the question of why approved decisions don't get implemented.

Step 7: Build access as a product capability

A data product isn't self-service-capable if every access request goes through a ticket.

Unity Catalog offers a hierarchical privilege model at the catalog, schema, and object level. Databricks recommends deliberately using this hierarchy model and organizing permissions through groups. (Databricks Docs)

For data products, I'd therefore make access models as predictable as possible.

For example:

customer_value_consumers
        |
        +-- SELECT customer_value_metrics
        +-- SELECT customer_value_current

customer_value_engineers
        |
        +-- MODIFY curated tables
        +-- manage pipelines

customer_value_admins
        |
        +-- MANAGE product schema

It gets even more interesting with attribute-based access control.

Unity Catalog ABAC uses governed tags as attributes on the basis of which policies can be applied dynamically. Databricks supports, among other things, row filters and column masks with this; corresponding rules can be defined at a higher level and automatically applied to matching assets. (Databricks Docs)

This is far more scalable for data products than:

More on exactly this: Scaling security with ABAC, tags, and automatic policies.

A product shouldn't have to reinvent security rules every time.

It should operate within a governance structure where rules can be derived from its properties.

Step 8: Lineage is part of the product contract

If a data product is consumed by other products or applications, changes need to happen in a controlled way.

Lineage is critical for this.

Unity Catalog automatically captures lineage for Databricks queries and can display it down to the column level. Lineage covers not just tables, but also jobs, notebooks, and dashboards, for example; with external lineage, assets outside Databricks can now also be included in the graph. (Databricks Docs)

This makes an important question answerable:

Imagine you want to replace:

customer_segment

with:

customer_value_segment.

Before you make the change, the data product owner should know:

That's not a nice architecture feature.

That's change management.

And that's exactly why lineage is part of the data product, in my view.

Not as a pretty visualization.

But as a prerequisite for controlled evolution.

Step 9: Make usage measurable

Product thinking doesn't end with:

The relevant question is:

Databricks system tables now give access to a wide range of operational information in the system catalog, including audit events, lineage, billing, compute, and other usage data. (Databricks Docs)

With:

system.access.table_lineage

you can, for example, programmatically examine which assets are read and written and which Databricks entities were involved. The lineage system tables maintain a rolling time window for these events. (Databricks Docs)

There's also:

system.query.history

a query history system table for SQL warehouses and supported serverless workloads. (Databricks Docs)

With this, a product team can ask questions like:

That's a completely different operating logic than:

A product that no one consumes is not a success.

Even if its pipeline graph is green.

Step 10: Also measure the product's cost

Data products don't just have value.

They incur costs.

This becomes especially relevant when domains are supposed to operate their own products.

Databricks provides billing information via system.billing.usage. Usage records can be attributed to resources, identities, and products, among other things; tags can also contribute to cost analysis. (Databricks Docs)

This lets us ask an uncomfortable but useful question for the first time:

Not just development.

But also:

This makes product thinking more complete.

Because a data product shouldn't only measure:

But rather:

Step 11: Version the product like software

A common anti-pattern looks like this:

For production data products, that's not enough.

Databricks has since renamed its former Asset Bundles to Declarative Automation Bundles. They're used to manage Databricks projects, including jobs and pipelines, as declarative project definitions and to support software engineering practices such as source control, testing, and CI/CD. (Databricks Docs)

For a data product, I'd therefore make as much as possible version-controllable:

customer-value/
│
├── databricks.yml
├── resources/
│   ├── pipeline.yml
│   └── jobs.yml
│
├── src/
│   ├── ingestion/
│   ├── transformation/
│   └── quality/
│
├── semantics/
│   └── customer_value_metric_view.yml
│
├── tests/
│
└── README.md

Not every element needs to sit exactly in this structure.

The idea matters more:

The product has a reproducible build and deployment process.

If you need to deploy customer_value to a new environment tomorrow, the answer shouldn't be:

Step 12: Define the consumer contract

Now we get to the actual product promise.

Suppose the data product publishes:

customer_id
customer_segment
net_revenue_12m
orders_12m
last_order_date

Then the consumer shouldn't just know the schema.

They should know:

Some parts can be operationalized directly in Databricks:

Other parts still require organizational agreements.

That's exactly why I wouldn't equate a data contract with a single Databricks feature.

The contract is the agreement.

Databricks implements part of it.

Step 13: Publish the product through the right interface

Not every consumer should see your internal Delta tables directly.

That's why I'd deliberately distinguish between internal implementation objects and published product interfaces.

For example:

For internal analytics, a Metric View can be the right interface.

For technical downstream systems, a table or view.

For external or cross-organizational use, Delta Sharing – see also Delta Sharing and Sharing data instead of copying it.

Databricks Marketplace uses Open Sharing for controlled access to data products. In Unity-Catalog-enabled workspaces, marketplace listings can include not just tabular data but also volumes, AI models, notebooks, and apps. (Databricks Docs)

This underscores an important point:

A data product in Databricks isn't necessarily just tabular data.

The product is the consumable offering.

The technical form depends on the consumer.

Step 14: Plan deprecation from the start

Data products are often published.

But rarely retired.

Yet that's exactly part of the lifecycle.

Suppose you replace:

customer_value_v1

with:

customer_value_v2.

Then you need a controlled transition.

For example:

v1
│
├── mark as Deprecated
├── identify consumers via lineage
├── publish replacement
├── communicate deadline
├── monitor remaining usage
└── remove after migration

v2
│
└── mark as Certified

The current discovery features in Unity Catalog support system-level trust signals such as Certified and Deprecated, which can appear in discovery and search. (Databricks Docs)

That's very useful.

Because suddenly lifecycle is no longer a wiki entry.

It becomes part of the platform.

Even more important:

With lineage and usage data, you can verify that really no one is still using the old version.

Only then do you delete it.

Not:

How I'd put a data product together in Databricks

If we bring everything together, roughly this model emerges:

None of these boxes alone is the data product.

The interplay is the product.

My minimal definition of a real Databricks data product

I'd only seriously call an asset a data product once I can answer at least these questions.

If you can't answer these questions, you probably have a good dataset.

Maybe even an excellently governed dataset.

But not yet a complete data product.

What Databricks takes off your hands

Databricks has become surprisingly good at centrally covering many technical properties of a data product.

Unity Catalog can provide governance and discovery. (Databricks Docs)

Lakeflow can operationalize processing and quality enforcement. (Databricks Docs)

Metric Views can centralize business metrics and semantics. (Databricks Docs)

Governed Tags and ABAC can make metadata and policies scalable. (Databricks Docs)

Lineage can make dependencies visible. (Databricks Docs)

System tables can make operations, usage, and cost observable. (Databricks Docs)

Delta Sharing and Marketplace can distribute products in a controlled way. (Databricks Docs)

Declarative Automation Bundles can make their technical implementation reproducible. (Databricks Docs)

That's a pretty complete technical toolbox.

What Databricks doesn't take off your hands

The platform still can't tell you:

Those remain organizational decisions.

And this is exactly where many data product initiatives fail.

Not because they lack features.

But because they hope the platform will replace product thinking.

It doesn't.

Maybe that's the actual architecture

If I had to build a data product in Databricks today, I wouldn't start with this question:

I'd start with this one:

After that, the platform can play to its strengths.

Lakeflow makes the product reproducible.

Delta makes its physical data foundation reliable.

Unity Catalog makes it governable.

Quality Expectations make rules enforceable.

Metric Views make business meaning more explicit.

Lineage makes dependencies visible.

System tables make usage and cost measurable.

Delta Sharing makes distribution controllable.

But only the consumer turns it into a product.

Because a Delta table answers:

Unity Catalog answers:

A Metric View answers:

And a real data product ultimately answers a different question: