# The unified trace table replaces inference tables, with one owner

> The Databricks unified trace table captures every Unity Gateway request in OpenTelemetry format. It is in Beta, and only its creator can read it.

By Ivan Vydrin, 9 October 2026. Databricks Field Guide, TechFabric. Canonical: https://databricks.techfabric.com/notes/the-unified-trace-table-replaces-inference-tables/

Databricks put the unified trace table into Beta on 21 August 2026. It captures every request and response across all Unity Gateway services into one Unity Catalog table in OpenTelemetry format, and the [documentation](https://docs.databricks.com/aws/en/ai-gateway/unified-trace-table) names it the recommended approach for new deployments, with inference tables kept for single model-service endpoint monitoring. A metastore admin sets it up once, and after that all Unity Gateway traffic is logged with no per-endpoint setup.

That last part is the design argument. Inference tables are configured per endpoint, which means the coverage of your AI logging is the sum of decisions made by whoever stood up each endpoint. Databricks describes the unified table as enforceable, with one setup and no blind spots from services that have logging disabled. If you have ever tried to answer "which model calls did this agent make last Tuesday" and found two of the four endpoints involved were never logging, you know what that buys.

## What it actually captures

Every span records the requester identity, the endpoint name and the full request payload. Databricks lists debugging by `trace_id` to replay a failed agent run, filtering by `service_name` and `status.code` to find errors on one endpoint, and running AI Functions over the table to analyse token usage patterns across callers, including coding assistants.

The OpenTelemetry format matters more than it sounds. Tooling that already exists in your estate can read the table, and nobody has to write a custom parser against a Databricks-shaped schema.

## The permission default will catch people

By default, only the metastore admin who creates the trace table can read it. Endpoint owners can't, the security team can't, nobody can, until the owner grants access through Unity Catalog. The setup also needs the extended Unity Gateway beta enabled from the account console Previews page, Unity Catalog on the workspace, metastore admin to create the table, and `CREATE TABLE`, `USE CATALOG` and `USE SCHEMA` on the target catalog and schema. A catalog backed by default storage needs a workspace admin to enable Zerobus Ingest Default Storage.

The operational risk is a table that exists, logs everything, and is unreadable by the one team that needed it during an incident. Grant `SELECT` to the security group at creation time, in the same change that creates the table, and write the grant into your bundle so it doesn't become a manual step later.

## It complements the audit log, it doesn't replace it

Databricks says trace delivery is best-effort and that the unified trace table complements the audit logs, which stay the system of record for compliance. Read that as written. If an auditor asks who invoked a model and when, the answer comes from audit logs. The trace table is for debugging, cost analysis and threat investigation, where a dropped span is an inconvenience rather than a finding.

> **Our position**: Stand the unified trace table up now in a non-production workspace and grant read to your security group in the same step, because one governed table beats per-endpoint inference logging you have to audit for gaps. Keep audit logs as the compliance record; Databricks says best-effort delivery, so treat the trace table as telemetry.

The thing to watch is the Beta label. Unity Gateway itself is generally available since 4 August 2026, but its beta capabilities are enabled separately, so a GA gateway doesn't mean GA tracing. Build the grants and the queries now, and keep the inference table on anything you would be unhappy to lose coverage of until the trace table leaves Beta.

## Related in the Field Guide

- [Pipelines declare tables, jobs run tasks, and you need both](/notes/pipelines-declare-tables-jobs-run-tasks-and-you/)
- [Lakeflow Jobs is the orchestrator, and its history is a queryable table](/notes/lakeflow-jobs-is-the-orchestrator-and-its-history/)
- [ai_decide is the cheap model you put in front of the expensive one](/notes/ai-decide-is-the-cheap-model-you-put-in/)
- On techfabric.com: [Unity Catalog for AI agents in practice: four FHIR scenarios](https://www.techfabric.com/blog/unity-catalog-agent-identity-row-filters-databricks)

## Questions people ask

### What is the unified trace table in Databricks?

It is a single Unity Catalog table that captures every request and response across all Unity Gateway services in OpenTelemetry format. Databricks announced it in Beta on 21 August 2026.

### Is the Databricks unified trace table generally available?

No. It is in Beta, and an account admin must turn on the extended Unity Gateway beta features from the account console Previews page before it can be used.

### Who can read the unified trace table?

By default only the metastore admin who created it. Other users, including endpoint owners and security teams, can't query it until the owner grants access through Unity Catalog.

## Related margin notes

- [Unity Gateway is GA, and the parts you wanted are still Beta](/notes/unity-gateway-is-ga-and-the-parts-you/)