Databricks AI Gateway routes across model providers but locks you into Unity Catalog, DBU billing, and Delta table logging. Here is what that means for mixed architectures.
Databricks markets its AI Gateway as a way to access any model provider "without locking teams into a single provider or stack." That claim is technically about model providers. It says nothing about the platform underneath.
The Databricks AI Gateway is the Databricks-native control surface for LLM traffic inside Databricks Model Serving. It attributes usage to Unity Catalog principals, applies AI guardrails, writes payload tables to Delta tables in Unity Catalog, and routes across Databricks Foundation Model APIs and external model endpoints that Databricks brokers (OpenAI, Anthropic, Bedrock, Cohere, Vertex, Azure OpenAI). You can swap out OpenAI for Anthropic in minutes. You cannot swap out Databricks.
As of April 2026, Databricks absorbed AI Gateway into Unity Catalog, renaming it Unity AI Gateway and extending Unity Catalog's governance model to agentic AI. The rebrand made the platform dependency structural, not incidental. The feature is currently in Beta, requiring account admins to enable it via the account console Previews page.
Model provider flexibility is the wrong lens for evaluating lock-in here. The real constraints are architectural.
The Databricks AI Gateway assumes the caller is a Unity Catalog principal and the endpoint is a Databricks model serving endpoint. If your organization authenticates through something else (Okta groups mapped to Kubernetes RBAC, AWS IAM roles, a custom identity layer) you are outside the gateway's design boundary. There is no adapter. Unity Catalog is the identity model, period.
Other gateways charge per request, per token, or nothing at all (open source). Databricks charges in DBUs, a proprietary metric representing processing power per hour. A single AI request can trigger multiple DBU-consuming events: gateway routing, guardrail execution, and Unity Catalog permission checks. DBU rates for AI workloads start at $0.07/DBU for foundation model serving and can exceed $0.70/DBU for serverless SQL operations used to analyze logs.
This is not just a pricing model. It is a forecasting problem. You cannot predict gateway costs without understanding how DBU consumption compounds across routing, guardrails, and log ingestion. That complexity is fundamentally tethered to the Databricks Unit model, specific compute tier selections, and platform-level dependencies like Unity Catalog.
Audit logging, monitoring, and observability all write to Delta tables inside Unity Catalog. Databricks surfaces this as a feature: "Monitor agent monitoring prompts, traces, token usage and tool activity with Lakewatch and Unity Catalog-governed inference tables." The flip side is that your entire LLM observability history lives in a proprietary format on a proprietary platform. Migrating that data out means rebuilding both the storage layer and every query that depends on it.
Even when routing to an external provider like OpenAI or Anthropic, Databricks requires an active serving endpoint. In high-concurrency environments, this may require provisioned capacity that prevents full scale-to-zero. You are paying Databricks compute costs to proxy a call to someone else's API.
The lock-in becomes a compliance risk for teams with mixed architectures.
Any external SaaS LLM call that goes directly from your application to OpenAI, Anthropic, or another provider without transiting Databricks is invisible to the gateway. The payload archive does not capture it. Your cross-endpoint audit pipeline ends up with partial coverage, which regulators under EU AI Act Article 12 or Fannie Mae LL-2026-04 will catch.
This creates an all-or-nothing dynamic. Either you route every LLM call through Databricks Model Serving, or you accept gaps in your audit trail. There is no middle ground.
For regulated industries, there is another constraint: Unity AI Gateway is not supported on AWS GovCloud or Azure Government. Teams in those environments cannot use the gateway at all, regardless of how invested they are in the Databricks ecosystem.
Databricks' product page says Unity AI Gateway lets teams "apply consistent governance across Databricks-hosted AI, external models, coding agents, agent harnesses, MCPs and AI frameworks without locking teams into a single provider or stack." The "provider or stack" in that sentence means model providers. The stack you are locked into is Databricks itself.
A customer quote from Udemy on the Databricks blog illustrates what adoption looks like in practice. Nathan Sullins, Principal Software Engineer at Udemy, describes how they "route all foundation model traffic through Databricks AI Gateway" to get unified access control and cost attribution across production agents running on Claude and PII detection pipelines balancing GPT models.
"Governance in one place" and "route all traffic through Databricks" are the same sentence. That is the trade-off. Unified governance requires total platform commitment.
The open-source AI gateway space includes options that do not assume a lakehouse runtime.
Kong AI Gateway and LiteLLM are the closest open-source alternatives. Both run in front of any LLM endpoint and do not assume a lakehouse runtime. The architectural distinction is the identity boundary: both are agnostic to the identity model and the runtime substrate. They run wherever your infrastructure runs. See our LiteLLM alternatives comparison for a deeper breakdown of that ecosystem.
The trade-off is real. These alternatives do not give you Unity Catalog's integrated governance out of the box. You build observability, access control, and AI cost attribution from separate components. But those components are portable. They work across clouds, across identity systems, and across billing models without a proprietary compute unit in the middle.
This is not a good-or-bad question. It is a boundary question.
Databricks AI Gateway fits when:
It does not fit when:
The Databricks AI Gateway solves a real problem for teams fully inside the Databricks ecosystem. For everyone else, the "no lock-in" promise applies to model providers but not to the platform that governs them.