# Databricks MLflow Managed Warehouse Beta: Trace Queries Without Manual Compute Setup

The new preview removes a step from inspecting agent traces, but the compute bill and SDK requirements remain.

By Paras Madan | 2026-11-03

Databricks dated its managed warehouse for MLflow beta November 2, allowing users to inspect Unity Catalog traces in the MLflow UI without choosing a SQL warehouse themselves. It simplifies the path from an agent problem to its trace, while leaving important compute and access requirements in place.

## What the MLflow beta changes

The [November release notes for Google Cloud](https://docs.databricks.com/gcp/en/release-notes/product/2026/november) describe an admin-enabled preview. Databricks cautions that releases are staged, so an individual account may receive the feature a week or more after the listed release date.

The change concerns the compute used to read traces. It does not mean that recording a trace, storing it and querying it have become the same operation, or that MLflow has stopped needing compute behind the interface.

For an engineer investigating an agent run, the benefit is straightforward: there is one less infrastructure choice between opening an experiment and seeing what happened. That is useful when the person debugging the application is not the person who manages its warehouses.

## How MLflow chooses compute

The [managed warehouse documentation](https://docs.databricks.com/gcp/en/mlflow3/genai/tracing/managed-warehouse) describes three options in order. An explicitly selected SQL warehouse takes priority. Otherwise, a workspace with Lakehouse//RT enabled can use a warehouse MLflow creates. Without that option, MLflow uses managed serverless compute. Serverless also fills the gap while the warehouse is being created.

The managed warehouse is restricted to MLflow UI interactions. Users can still choose a warehouse through Trace compute.

## Billing and access still matter

Normal SQL warehouse or serverless compute billing applies. Trace analysis is not free.

The feature requires an administrator to enable the preview, traces stored in Unity Catalog, permission to select from the trace tables, and a workspace in a serverless-supported region. Lakehouse//RT is optional.

There is also a clear boundary: **the beta applies to the MLflow UI**. The Python SDK still needs a SQL warehouse.

That boundary matters for teams with both interactive debugging and automated analysis. Enabling a convenient interface should not be mistaken for migrating the scripts that evaluate runs or produce recurring reports.

## Why this is an observability change

An agent can fail for reasons that are hard to see from its final answer: a tool returned the wrong data, a retrieval step missed relevant context, or an intermediate instruction changed the response. A trace helps turn that outcome into a sequence that can be investigated.

Removing setup friction makes that investigation easier to start. It does not establish that the trace is complete, that the evaluator is sound, or that the agent is reliable. Those remain separate engineering responsibilities.

The useful test for this preview is therefore not simply whether it opens faster. It is whether more people on the team can inspect a problematic run without losing visibility into permissions, compute ownership and cost.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders explain developer infrastructure and product updates without turning them into generic marketing.

[Book a 30-minute call](https://cal.com/paras-madan/30min).