Databricks Apps: Building data apps at the speed of thought

Introduction

Have you ever been bothered by how long it can take for your data to deliver value to your business? Thanks to Databricks’ new product: Databricks Apps, you can create working application on top of the data that already exists on your Lakehouse platform.

On top of that, no more worrying about setting up infrastructure, load balancing, proxies or anything like that. Databricks will do it all for you at a convenient price. You can also seamlessly integrate any other service from Databricks that you might already be using; like Genie or ML models. Though it might not all be as perfect as it seems.

In this blog post I will investigate the advantages, disadvantages and noteworthy features that Databricks Apps offer. I’ll also explain why calculating it’s pricing can be a bother and what the future has in store for Databricks Apps.

So, what exactly are Databricks Apps?

At its core, Databricks Apps is just app hosting that’s built right into your workspace. You skip the usual dance of building something and then figuring out where it’s going to live. There’s no infrastructure to spin up, no DevOps ticket to file, no waiting on someone else’s queue. You write it, deploy it, and it lives right next to your data.

That opens a lot of practical, internal stuff people need. Think a simple manager for your Databricks Jobs, so someone on the team can kick off a run or check on why something failed without having to dig through the Jobs API themselves. Or a basic CRUD interface sitting on top of Lakebase, so people who don’t write SQL can still add, edit, or look up records through a normal form instead of pinging you every time. You could even take an internal chatbot, say something built on Mosaic AI for the sales team, and give it a proper chat interface so people can just ask it questions about accounts or pipeline instead of digging through dashboards.

And honestly, self-service analytics might be the most common use case of all: letting business teams poke around curated data or filtered views on their own, instead of sending the data team the same requests repeatedly.

The nice part is none of these needed their own hosting setup or deployment pipeline. They just sit alongside your notebooks and tables like they’d always belonged there.

It supports a range of popular frameworks like Streamlit, Gradio, Dash, Flask, FastAPI and even React, and works with both Python and JavaScript. Apps are deployed with a single click from the workspace UI or via the Databricks CLI.

What sets it apart is what you get out of the box:

• Direct access to Unity Catalog, SQL Warehouses and MLflow models, no credential management required
• OAuth SSO built in, users log in with their existing Databricks account
• Apps run as a dedicated service principal with granular permission control
• Secrets and environment variables injected at runtime, no hardcoded credentials

Example of where Apps situate themselves in the Databricks Architecture

Built on three pillars

The reason Databricks Apps feels different from just deploying a Streamlit app somewhere is that it is genuinely integrated into the platform at three levels.

Unified Compute. Apps run on Databricks serverless compute alongside your notebooks, jobs and SQL warehouses. No separate runtime to manage, no cluster configuration, and no separate billing for the infrastructure. Cloud compute is bundled into the DBU rate.

Governed Data. Your app reads and writes Delta Lake tables through Unity Catalog, with the same row-level security and column masking that apply everywhere else. Data never leaves the platform, and access is tied to the user’s identity automatically.

Integrated AI. Every AI capability in Databricks, from MLflow Model Serving and Vector Search to Foundation Model APIs and Agent Bricks, is directly accessible from your app. You call a model the same way a notebook cell would, with no artifact copying and no external API keys to manage.

The advantages over conventional hosting

If you have ever deployed a data app the traditional way, spinning up a VM or container, writing a Dockerfile, setting up authentication, managing credentials, wiring up a reverse proxy, you will appreciate what Databricks Apps removes from that list.

• Zero infrastructure overhead, no VMs, load balancers, or containers to configure or maintain
• Native data access, apps talk to Delta tables and ML models over the internal data plane, not the public internet
• Unified security, OAuth SSO, Unity Catalog permissions and network isolation are built in, not bolted on
• Lower total cost, one platform for data, ML and apps means one bill, not three

What does it actually cost?

Pricing is where things get a bit more nuanced, and where it is easy to get caught off guard.

Databricks Apps are billed in DBUs (Databricks Units), and the most important thing to understand is this: an app incurs costs if it is in the “Running” state, even if nobody is using it. There is no automatic idle scale-to-zero for a running app. To stop the billing, you must explicitly stop the app.

The good news is that stopped apps preserve their full configuration and restart quickly. A practical trick: use a Databricks Job on a schedule to stop the app at the end of business hours and start it again in the morning. That alone can cut your app compute costs by 60 to 70% compared to leaving it running around the clock.

A few other things worth knowing:

• There are multiple compute tiers (Small, Medium, Large), pick the right one for your workload
• Cloud compute is bundled into the DBU rate for Apps, unlike most other Databricks products where you get a separate cloud VM bill
• Downstream services like SQL Warehouses, Model Serving and Vector Search are billed separately on top
• Rates vary by cloud provider, region, and tier, so always check the official Databricks pricing page

As a rough ballpark: an always-on end-user dashboard runs around 550 to 600 EUR/month, while an internal tool with limited uptime can be closer to 100 EUR/month.

It’s not all perfect

Before you commit, there are a few real limitations worth knowing about.

• Databricks-only. Your app is tied to the Databricks ecosystem. Migrating to a standalone host later means refactoring.
• Start/stop latency. Apps on shared compute can take 30 to 90 seconds to start after being idle. Not ideal for latency-sensitive use cases.
• No custom domains (yet). Branded URLs require additional workspace configuration and are not yet self-service.
• Basic observability. Built-in logging is functional but limited. Advanced APM or distributed tracing requires external tooling.
• Unpredictable pricing. The DBU model can be hard to budget for upfront, especially if downstream services scale unexpectedly.
• Not for external customers. While Databricks Apps really help to democratize data within your enterprise, it is not designed for customer-facing applications.

Noteworthy features

Beyond the headline capabilities, a few features stand out for anyone building production-grade apps.

Service Principal OAuth with OBO auth. Each app runs as its own service principal. The caller’s identity is passed through (on-behalf-of), giving you fine-grained, per-user access control without writing a single line of auth code.

Isolated environments per app. Each app gets its own Python environment with dedicated package management. No dependency conflicts with notebooks or other apps, and JS runtimes are supported too.

Native secrets integration. Databricks Secrets are injected as environment variables at runtime. No hardcoded credentials, no secret scanning headaches.

What’s coming

The product is evolving fast. A few announced features worth keeping an eye on:

• Micro-Apps with true scale-to-zero, finally addressing the idle cost problem
• Genie App Builder, generate apps directly from natural language on top of your data
• Custom domain names, branded URLs as a self-service workspace feature
• Horizontal scaling and multi-region deployment for high-availability production workloads
• App Templates Gallery, one-click starters for common use cases

Example of Genie App Builder

The bottom line

Databricks Apps closes the last gap in the Lakehouse platform: going from data and models to live, interactive applications, all within a single governed environment. For teams already on Databricks, the value proposition is hard to argue with. You get faster time-to-value, unified governance and a significantly smaller infrastructure footprint.

That said, it is not a silver bullet. The pricing model takes some getting used to, cold starts are a real consideration, and you are making a bet on the Databricks ecosystem. But with scale-to-zero on the roadmap and the pace at which the platform is moving, those rough edges are shrinking fast.

If your team is building on the Lakehouse and you have been shipping data apps the old-fashioned way, Databricks Apps is absolutely worth a serious look.

Written by