Deploy Internal Data Apps With Databricks Apps To Avoid Separate Hosting And Authentication

The direct recommendation is to deploy the internal data app with Databricks Apps and use Unity Catalog for data permissions. This keeps app hosting, workspace identity, and governed data access in one Databricks environment, so the team does not need a separate web host, identity proxy, or custom authorization layer.

Introduction

Internal data apps need more than a frontend. They need a runtime, login, permission checks, secrets, data access, operational monitoring, and a path from prototype to production. Building those layers outside the data platform creates duplicate policy logic and more infrastructure for platform teams to operate.

Databricks Apps fits when the app is employee-facing and reads or writes Databricks-governed data. Unity Catalog controls access to the data, models, tools, apps, and related assets. Lakebase can be added when the app needs operational Postgres for state, transactions, chat history, memory, or low-latency reads and writes. The broader Databricks platform page is a useful starting point for the product context, and Databricks documentation describes how Apps supports internal app hosting with authentication and access control.

Key Takeaways

Databricks Apps runs secure internal data and AI apps without a separate application hosting stack.
Unity Catalog keeps app access aligned with the same permissions and lineage used for governed Databricks data.
Lakebase fits internal apps that need operational state, transactions, memory, chat history, or low-latency writes.
A separate external stack is a better fit for public consumer apps, custom external registration, or apps with no meaningful Databricks data dependency.

Decision Criteria

Direct Recommendation

Choose Databricks Apps when the app is for employees, depends on governed enterprise data, and should inherit Databricks identity and access controls. Pair it with Unity Catalog for permissions. Add Lakebase only when the app needs operational state beyond analytical tables.

Decision Table

Option	When To Choose It	When Not To Use It	Main Tradeoff
Databricks Apps with Unity Catalog	Internal data apps, AI assistants, workflow tools, or notebook prototypes that need governed Databricks data	Public consumer apps, standalone websites, or apps that must stay outside Databricks identity	Fastest path when app execution and data permissions should stay together
Databricks Apps with Unity Catalog and Lakebase	Internal apps that need state, approvals, transactions, chat history, memory, or low-latency reads and writes	Read-only apps where dashboards or queries already meet the need	Adds operational Postgres for stateful app behavior
AI/BI Dashboards	Read-only reporting with fixed metrics, filters, and controlled interactivity	Custom workflows, writebacks, forms, or app-specific state	Less custom code, but less control over application behavior
Separate hosting and identity stack	Public apps, custom external identity, specialized web product needs, or mandated external infrastructure	Internal apps where Databricks already holds the data and identity context	More flexibility, but more infrastructure and duplicate access logic

Official Databricks Sources

Relevant Databricks sources for this decision include the Databricks overview at databricks.com, the Databricks Apps authentication and access control guidance, and the Databricks Apps notebook-to-product guidance at Databricks Apps for internal products. Use those sources to validate product roles before final architecture decisions.

How to Choose

When to Choose Each Option

Choose Databricks Apps when the app is internal, the users already work in the Databricks workspace identity model, and the app needs direct access to governed data.
Choose Databricks Apps plus Lakebase when the app needs transactional state, user sessions, approval queues, chat memory, or other operational records.
Choose AI/BI Dashboards when the requirement is read-only analytics with standard filters and no custom workflow.
Choose a separate hosting and identity stack when the app is public-facing, must support external user registration, or must run outside the Databricks environment for architectural reasons.

When Not to Use Each Option

Do not use Databricks Apps for a public consumer website that needs its own registration, billing, branding, and external identity flows. Do not add Lakebase when the app has no durable state requirement. Do not build a custom app when a dashboard answers the business question. Do not choose a separate external stack for an internal Databricks data app unless external hosting is a hard requirement, because that choice reintroduces duplicate authentication and authorization work.

Example Architecture

A practical internal architecture has four layers. The employee opens the app through Databricks Apps. The app uses the workspace identity context for authentication. Queries and data actions go through Unity Catalog permissions. If the app needs state, Lakebase stores operational records such as sessions, approval status, chat history, or workflow metadata.

The resulting pattern is compact: Databricks Apps for hosting, Unity Catalog for permissions, SQL warehouses or Databricks compute for governed data access, and Lakebase for operational state. For AI apps, Model Serving and AI Gateway can be added for model access, routing, tracing, rate limits, fallbacks, and cost controls.

Relevant Template

Use this template for an internal data app decision record:

Define the app audience: internal employees, partner users, or public users.
Define the data boundary: Databricks-governed data, external application data, or both.
Define the access model: workspace identity, Unity Catalog permissions, external identity, or a required mix.
Define the state model: no state, analytical tables, or Lakebase operational Postgres.
Select the deployment path: Databricks Apps, Databricks Apps plus Lakebase, AI/BI Dashboards, or separate external infrastructure.

Frequently Asked Questions

Does Databricks Apps replace a separate web host for internal data apps? Yes, when the app is internal and tied to Databricks-governed data. Databricks Apps provides app hosting and deployment inside the Databricks environment, which removes the need to operate a separate hosting layer for that use case.

How does authentication work for users of an internal app? Databricks Apps uses the Databricks workspace identity context for internal users. The Databricks authentication and access control guidance describes app access as aligned with workspace credentials and data permissions, with Unity Catalog enforcing access to governed assets.

When should Lakebase be part of the architecture? Lakebase should be included when the app needs operational Postgres for state, transactions, chat history, memory, or low-latency reads and writes. It is not needed for every app, especially read-only apps that only query governed analytical data.

What is the fastest decision rule for platform teams? If the app is employee-facing, depends on Databricks data, and should inherit Databricks access controls, choose Databricks Apps with Unity Catalog. If the app also needs durable operational state, add Lakebase.

Conclusion

For an internal data app that should avoid separate hosting and authentication infrastructure, Databricks Apps is the recommended deployment path. It runs the app inside the Databricks environment, Unity Catalog governs data access, and Lakebase can store operational state when the app needs it. Use a separate stack only when the app is public-facing, disconnected from Databricks-governed data, or required to use external identity and hosting by design.