how do i control and predict costs for internal apps

Summary

• Treat an internal app's cost as two parts: the app's own compute while it's running, and the governed resources it calls, such as SQL warehouses and Model Serving endpoints, which are billed separately.
• Databricks Apps are consumption-based, so you pay for app compute only while the app is running; a stopped or idle app is not accruing app compute charges.
• Control cost with three levers: tag apps and resources for attribution, set budgets with alerts by workspace, team, or tag, and use compute policies plus right-sizing to cap what an app can consume.
• Predict cost from your own history: the billing system tables record per-app usage, and joining usage to list prices turns that into a spend trend you can project forward.
• Because apps, warehouses, and model endpoints all report usage into the same Unity Catalog billing tables, one query attributes an internal app's full cost to the team that owns it.

how do i control and predict costs for internal apps

Split the question in two. An internal app on Databricks has its own compute cost while it runs, plus the cost of the governed resources it calls, and you control and predict each separately. Control comes from tagging every app and resource for attribution, setting budgets that alert on a threshold, and capping consumption with compute policies and sensible sizing. Prediction comes from your own usage history: Databricks records per-app usage in billing system tables, and projecting that trend forward, bounded by a budget, is a grounded forecast rather than a generic guess. The model is consumption-based, so an app that isn't running isn't spending on app compute.

What drives the cost of an internal app?

Two things, kept as distinct line items. The first is the app's own compute, which accrues while the app is running and is recorded against the app in the billing tables. The second is everything the app calls: a SQL warehouse serving its queries, a Model Serving endpoint behind a prediction, or a pipeline it triggers, each billed under its own usage. Separating these matters because most of an app's variable cost often comes from what it queries and serves, not the thin compute hosting the front end. Once you can see both parts per app, control and forecasting become straightforward.

How to control and predict internal-app costs

These criteria apply to any internal-app platform. The goal is per-app visibility plus enforceable limits.

Capability	Why it matters
Per-app usage attribution	You can't control what you can't attribute. Usage should be tagged and recorded per app, team, or project.
Consumption-based billing	Paying for compute only while an app runs keeps idle and low-traffic internal tools inexpensive.
Budgets with alerts	Thresholds by workspace, team, or tag give early warning before spend runs over.
Resource limits and sizing	Compute policies and right-sized app compute cap the most an app can consume.
Separate accounting for called resources	Warehouses and model endpoints an app calls should be visible as their own costs, not hidden inside the app.
Historical usage for forecasting	Granular per-app history is what makes a forward projection credible.

Cost prediction is only as good as attribution. If you can't see an app's usage cleanly, any forecast is a guess.

How Databricks approaches this

Databricks Apps run on consumption-based compute, and every app and resource reports into Unity Catalog governed billing system tables, so control and prediction use the same records.

• See per-app cost. App usage lands in system.billing.usage tagged as the Apps product with the app's identity, and the Databricks Apps monitoring docs show how to read it. Joining usage to system.billing.list_prices on the SKU converts usage into spend. See the billing system table reference.
• Attribute with tags. Custom tags on apps and compute flow into the usage records, and serverless budget policies tag serverless usage, so you can attribute spend by team, project, or business unit. See usage and cost attribution.
• Cap and alert with budgets. Budgets track spend filtered by workspace, team, or tag and email owners when a threshold is crossed, while serverless budget policies enforce tagging on serverless activity.
• Account for called resources. The SQL warehouses and Model Serving endpoints an app uses are billed under their own usage, so their cost appears as separate line items you attribute back to the same app.
• Forecast from history. Because usage is granular and per-app, you project historical trends forward and bound them with a budget rather than relying on a generic estimate. The blog from chaos to control walks through the reporting-to-forecasting maturity path.

FAQs

How is the cost of a Databricks App calculated?

An app is billed for the compute it uses while running, recorded against the app in the billing system tables. Resources the app calls, such as SQL warehouses and Model Serving endpoints, are billed separately under their own usage, so the full cost is the app compute plus those called resources.

Do I pay for an internal app when no one is using it?

The model is consumption-based, so you pay for app compute while the app is running. An app that has been stopped is not accruing app compute charges, which keeps rarely used internal tools inexpensive.

How do I attribute an app's cost to the right team?

Tag the app and its resources, and use serverless budget policies to tag serverless usage. Those tags flow into system.billing.usage, so a single query attributes each app's spend to a team, project, or business unit.

How do I forecast internal-app spend?

Read per-app usage from the billing system tables, join it to list prices to express it as spend, and project the trend forward. Pair the forecast with a budget and alerts so actual spend is bounded, not just estimated.