Databricks Unity AI Gateway vs Portkey (2026): AI Gateway and Governance Compared

Three shapes on the same ten axes. Unity AI Gateway (orange) and Portkey (violet) track each other closely on the gateway spokes — Portkey edges ahead on Gateway & Policy Control and Observability (9 to 8 on both) and they tie at 8 on Guardrails — then split hard on Deployment Sovereignty: 9 for Portkey's self-host-to-air-gap ladder against 3 for a Databricks-managed-only service. Unity AI Gateway holds a slight edge on Agent Containment (5 to 4) through hard budget blocks and contextual policies. Both cluster at 5 on the inventory and compliance axes — the gateway category's signature. Kosmoy (blue) trades a little raw gateway breadth for reach across inventory, compliance and agent containment. Read it as area: the two gateways compete spoke by spoke; the suite covers the web.

Governance woven into the data estate. External MCP servers register as Unity Catalog securables with fine-grained permissions, tool filtering and centralized audit, alongside managed integrations for Google Drive, Jira, Confluence, Slack, GitHub and SharePoint (MCP governance blog) — and every policy decision lands in the same catalog that already governs the data. Portkey's registries govern what is routed through Portkey; they do not live in your data catalog.

Budgets with a documented hard-block lifecycle. Hit a threshold and the gateway can alert — or block further requests until the budget resets or an admin raises it, with per-user and per-budget spend views (budgets docs); cost observability extends to enriched billing records attributing spend across users, teams, applications, models and providers (cost observability docs) — finance-grade tables Portkey's per-key budgets and metrics do not reach into a billing system.

Agent-action policies in the request path. Contextual Service Policies (Beta) can allow, deny or require approval for agent actions such as modifying files or pushing code (guardrails docs) — an approval workflow Portkey does not document; its agent gateway controls skill-level access rather than gating individual actions for approval.

Consumption pricing inside existing billing. Routing, rate limits, fallbacks and traffic splitting are free; payload logging and usage tracking bill through the DBUs a Databricks shop already meters (pricing) — no second vendor contract, procurement cycle or per-seat tier to negotiate.

Model and provider breadth. One API to 250+ LLMs and 1,600+ models across 45+ providers (gateway repo), against Unity AI Gateway's documented set — OpenAI, Anthropic, Cohere, Bedrock, Vertex AI and OpenAI-compatible endpoints (external models docs).

A deployment ladder Databricks does not offer. MIT open-source self-host, hybrid with the data plane in your VPC, or a documented fully air-gapped enterprise deployment (self-hosting docs). Unity AI Gateway runs only as a Databricks-managed service — no self-hosted, on-prem or air-gapped option is documented as of August 16, 2026.

Observability depth. Full request logging with 21+ metrics, per-key budgets and rate limits, OpenTelemetry and data-lake export (observability docs) — a 9 on the radar against Databricks' strong but newer 8, and it exports to your stack rather than living in platform system tables.

No platform commitment, and an open core. The MIT gateway (~12.4k stars) adopts without a Unity Catalog workspace, DBU billing or a Databricks relationship — for an estate that spans Snowflake, bare Kubernetes and three clouds, the gateway does not pull AI governance into one vendor's platform.

Longer-shipping gateway surface. Portkey's guardrails, MCP gateway and (since April 2026) agent gateway with skill-level access control predate Unity AI Gateway's August 2026 GA, where service policies, agent services and Smart Routing are still marked Beta (GA blog) — though Portkey's own last open-source gateway release predates its acquisition.

Both products govern the traffic that opts in: an app or coding agent points its base URL at the gateway and inherits budgets, guardrails and logs. Neither documents what a regulated enterprise is increasingly asked to prove — an estate-wide inventory of AI running outside the gateway, evidence against the EU AI Act, ISO/IEC 42001 or NIST AI RMF, or kernel-enforced containment for agents that act. Unity AI Gateway's inventory covers assets registered in Unity Catalog; Portkey's covers assets routed through Portkey; both stop at their own perimeter as of August 16, 2026. When those are the ask, the category changes — from gateway to control plane, the frontier mapped on the AI capability map.

Kosmoy includes the gateway both products are — one OpenAI-compatible policy point with guardrails, RBAC, budgets and logging — but wraps it in the layers a gateway leaves out: a risk-tiered inventory of every model, MCP server and agent across the estate, including a master agent registry that pulls from Foundry, Bedrock, Vertex, Salesforce and ServiceNow; EU AI Act, ISO 42001 (aligned) and NIST AI RMF evidence built from registry state plus gateway logs; and kernel-enforced Action Capsule containment with a kill switch. The direct head-to-heads live at Kosmoy vs Databricks Unity AI Gateway and Kosmoy vs Portkey.

So the honest framing is not “Kosmoy beats Unity AI Gateway and Portkey at being a gateway” — Databricks integrates deeper into its own estate and Portkey routes to more models. It is that a gateway covers two or three spokes of the ten-axis map. If the requirement is the whole web — inventory, gateway, compliance and containment in one self-hosted platform — that is a suite decision, not a gateway decision.

For a team whose problem genuinely is model traffic, pick on the estate: Unity AI Gateway if Databricks is where AI already lives and consumption billing beats a new contract; Portkey if the gateway must span stacks, export observability to your own tools, or run air-gapped. Both are OpenAI-compatible, so applications move with a base-URL change — the sticky parts are Unity Catalog registrations on one side and Portkey configs and logs on the other. Some enterprises run both today: Unity AI Gateway for workloads inside Databricks, Portkey for everything else.

For an enterprise that has to prove control over all of its AI — not just route it — the choice is not between these two gateways but between a point tool and a suite. Kosmoy can coexist with either: some teams keep Unity AI Gateway for lakehouse workloads or Portkey for developer experimentation while Kosmoy holds the estate-wide inventory, compliance evidence and containment for what reaches production.