Migrate from Databricks Metric Views

Databricks metric views define governed measures and dimensions over your Delta tables in Unity Catalog. Credible reads that definition, rebuilds it as Malloy, and — where you connect the workspace — validates each measure with the same MEASURE() queries you'd run in Databricks.

What Credible Reads

Your Unity Catalog metric views — YAML definitions with a source, dimensions, measures, joins, and an optional top-level filter. The agent works from that YAML. Connecting to the workspace is optional but the natural way to fetch and validate it: pull the definition with DESCRIBE TABLE EXTENDED <catalog.schema.view> AS JSON, discover views through Unity Catalog's information_schema, or read through a Genie / AI-BI space where one is configured (measures are read only through the MEASURE() function).

What Comes Across

The everyday modeling carries over. Here's how the bigger pieces land — and where they get better:

The Migration Flow

Credible reads the metric-view YAML, translates the source, joins, dimensions, and measures to Malloy, enriches with #(doc)/#(index) tags, and — where the workspace is connected — validates row-by-row with SELECT <dim>, MEASURE(<measure>) … GROUP BY ALL.

What Credible Handles

• MEASURE()-only access — metric-view measures can't be read as plain columns, so Credible mirrors each aggregate expression, preserving semi-additive behavior instead of blindly re-aggregating.
• Unity Catalog governance — grants, row filters, and column masks live in Unity Catalog and do not travel with the YAML. Credible re-establishes equivalent controls in its own access-control layer rather than pretending they came along.
• Upstream joins — because joining a metric view to other tables requires wrapping it in a CTE, those joins are modeled explicitly as Malloy sources and joins.

Before & After

A Unity Catalog metric view:

version: 1.1
source: samples.sales.orders
comment: "Order metrics with customer attributes"
filter: o_orderdate >= '2024-01-01'
joins:
  - name: customer
    source: samples.sales.customer
    on: source.customer_id = customer.customer_id
    cardinality: many_to_one
dimensions:
  - name: Order Status
    expr: order_status
  - name: Order Month
    expr: DATE_TRUNC('MONTH', o_orderdate)
measures:
  - name: Total Revenue
    expr: SUM(amount)
    format: { type: currency }
  - name: Completed Revenue
    expr: SUM(CASE WHEN order_status = 'completed' THEN amount END)
  - name: Avg Order Value
    expr: SUM(amount) / NULLIF(COUNT(1), 0)

source: orders is conn.table('samples.sales.orders') extend {
  primary_key: order_id
  join_one: customer is conn.table('samples.sales.customer') on customer_id

  where: o_orderdate >= @2024-01-01

  dimension:
    #(doc) Order status
    #(index)
    status is order_status

    #(doc) Customer segment
    #(index)
    customer_segment is customer.segment

  measure:
    #(doc) Total revenue in USD
    # currency
    total_revenue is sum(amount)

    #(doc) Revenue from completed orders
    # currency
    completed_revenue is sum(amount) { where: status = 'completed' }

    #(doc) Number of orders
    order_count is count()

    #(doc) Average order value
    # currency
    avg_order_value is total_revenue / order_count

  view:
    #(doc) Revenue by month
    revenue_by_month is {
      group_by: o_orderdate.month
      aggregate: total_revenue
    }
}

The top-level filter becomes a source-level where:, aggregate expressions become measures (a SUM(CASE WHEN …) becomes a clean { where: … } filter), and format maps to render tags. Governance stays behind in Unity Catalog and is re-created in Credible.

More than a reformat. The model is AI-usable through the AI Analytics Engine and composes into follow-up questions your MEASURE()-bound metric views couldn't express. See what you gain →

Next Steps