How Databricks moved from “the place where data work happens” to a governed runtime for applications, agents, and operational intelligence.
1. Applications that run where the data lives
Databricks Apps lets teams deploy interactive, user-facing applications directly in the workspace on managed serverless compute. The value is not simply that developers avoid standing up Kubernetes. The application can use workspace identity, service principals, governed resources, private networking, and Unity Catalog permissions without recreating those controls in a separate hosting tier.
Three years ago, “we built it in Databricks” usually meant a notebook or scheduled workload. Today it can mean a production operations console, a review workflow, a data-quality cockpit, or an AI application used every morning by business teams.
Databricks Apps: Apps can use Lakebase databases as managed resources, with credentials injected for the app service principal. The 2026 releases also added richer app resources, compute sizing for compliance profiles, application telemetry in Beta, horizontal scaling in Beta, and Marketplace installation for third-party apps.
2. A real transactional database, natively
Applications need state: user actions, workflow status, approvals, configuration, agent memory, and transactional updates. Historically that meant provisioning PostgreSQL elsewhere and maintaining another credential model, network path, backup plan, and synchronization process.
Lakebase brings PostgreSQL-compatible operational storage into the Databricks platform. Its autoscaling architecture supports scale-to-zero, high availability, branching, snapshots, and instant restore. When attached to Databricks Apps, it gives the application a durable transactional backend while analytical data remains governed in the Lakehouse.
Lakebase Autoscaling: Lakebase became generally available for supported compliance profiles in March 2026. New databases now use autoscaling by default, including scale-to-zero, branching, point-in-time restore, budget policies, tags, and high availability. OpenTelemetry export for operational logs and metrics is available in Beta.
3. Agents you can actually put into production
Agent Bricks is the clearest signal of how far the platform has moved. Teams can assemble knowledge assistants, Genie Agents, custom agents, and supervisor-style systems rather than stitching together an unmanaged collection of prompts, vector stores, tools, credentials, and tracing libraries.
A Supervisor Agent can coordinate specialized capabilities: Genie Agents for structured data, knowledge assistants for documents, Unity Catalog functions for governed actions, AI Search indexes for retrieval, custom agents running in Databricks Apps, and MCP servers for external systems. Developers can still use frameworks such as LangGraph when they need full control, but the surrounding lifecycle—deployment, permissions, tracing, evaluation, and tool governance—can stay on the platform.
Model Context Protocol is especially important. It gives agents a standard way to use tools without hard-coding every integration into the application. The enterprise requirement, however, is not merely connectivity; it is governed connectivity with centrally managed credentials, permissions, logs, and reviewable tool calls.
Agent Bricks and MCP: In 2026, Supervisor Agent added custom MCP servers, custom agents hosted in Databricks Apps, Unity Catalog tables, and vector/AI Search indexes as subagent tools. Managed OAuth flows simplify external MCP authentication. Unity AI Gateway governance for MCP interactions remains Beta, while MLflow trace storage in Unity Catalog is Public Preview.
4. Any model, one contract, no re-architecture
In 2023, choosing a model provider often became an architectural commitment. SDKs, authentication, payload formats, quotas, and failure behavior leaked into application code. That was a poor fit for a market where model quality, price, latency, and context limits changed every quarter.
Databricks Model Serving and Foundation Model APIs provide a common access layer for Databricks-hosted and external models. Traffic splitting, fallbacks, rate limits, endpoint telemetry, and priority serving allow teams to optimize reliability and economics without rebuilding the application each time the model portfolio changes.
The point is not that every model is interchangeable. It is that the application can depend on a governed model service and routing policy rather than a single provider-specific implementation.
Foundation models and governed model services: The 2026 catalog expanded with new OpenAI, Anthropic, Google, and open-model releases. Model services in Unity Catalog are in Beta, allowing teams to define a governed LLM endpoint once and share it across workspaces through Unity Catalog privileges. Unity AI Gateway can manage routing, fallbacks, budgets, and capacity across providers.
5. Governance and observability across the entire AI stack
This is the capability that matters most in regulated industries—and the hardest one to bolt on after applications are already in production. Unity Catalog governs data and AI assets. Unity AI Gateway extends the control plane to runtime interactions among models, agents, coding tools, MCP servers, and external services.
The combined architecture supports access control, governed tags, sensitive-data classification, lineage, usage telemetry, model and tool permissions, request routing, guardrails, and audit trails. MLflow tracing captures how an agent arrived at an answer; evaluation can measure quality, latency, cost, safety, and human feedback.
Three years ago, “who approved this model to see that data?” was often answered through a spreadsheet and an investigation. The architectural goal now is to answer it through platform metadata, privileges, traces, and policy logs.
Unified governance: Databricks Data Classification is GA and can automatically classify and tag sensitive data in Unity Catalog. Cross-engine ABAC and governed model services continue to mature. Unity AI Gateway is Beta and now governs LLM endpoints, agents, coding agents, and MCP servers from one control plane.
Why this matters
Each capability is useful on its own. Together they eliminate the most expensive step in enterprise AI: moving data out of its governed home to make it useful. Every copy into another application stack creates a new security surface, a synchronization job, another version of the truth, and another operating model.
When to build on Databricks—and when not to
Build on Databricks when the application is fundamentally about enterprise data: it reasons across many source systems, requires governed semantic context, supports analytical or operational workflows, or must provide lineage and auditability for every answer and action.
Build natively in a system of record when the work belongs inside that product’s workflow—for example, acting on a case, opportunity, or patient interaction inside an established CRM or clinical platform. The strongest architectures are usually hybrid: Databricks provides the governed data foundation, cross-system intelligence, and heavy analytics; native platforms deliver the final action where users already work.
Been dabbling? Want to start?
Bring us the use case you have been circling. We will tell you whether it belongs on the Data Intelligence Platform, what the production architecture requires, how to control cost and risk, and what business return to expect.
Vertex Tower, Plot no-
C-33, 4th Floor, Phase 2, Industrial Area, Sector 62, Noida, Uttar Pradesh, 201309