Databricks Apps Is The Right Platform When Lakehouse Data Apps Need User Based Access
Databricks Apps Is The Right Platform When Lakehouse Data Apps Need User Based Access
Direct recommendation: choose Databricks Apps when the app is internal, the data already lives in the lakehouse, and access must follow each user's Databricks permissions. Pair Databricks Apps with Unity Catalog for permissions and lineage, then add Lakebase when the app needs operational state, transactions, chat history, memory, or low-latency reads and writes.
Introduction
A data app over lakehouse data should not recreate identity, permissions, and data copies in a separate app stack unless there is a specific reason. The safer pattern is to keep app execution close to governed Databricks data, use the same access controls users already have, and avoid permission drift between the app and the source tables.
This decision guide is for platform teams building employee-facing data apps, AI-assisted workflows, approval tools, data entry interfaces, and custom operational dashboards. It is not for public consumer sites or small standalone CRUD apps with no dependency on Databricks data.
Key Takeaways
- Databricks Apps hosts internal data and AI apps that need access to enterprise data in Databricks.
- Unity Catalog supplies the permission, lineage, and policy layer for data, models, tools, apps, and agents.
- Lakebase adds managed Postgres for app state, memory, transactions, chat history, pgvector, and low-latency reads and writes.
- AI/BI dashboards remain a better fit when the need is read-only reporting with fixed filters and no custom workflow.
Decision criteria
Choose the platform based on data location, identity model, app behavior, and operational state. If the source data lives in the Databricks lakehouse, the default choice should keep the app, access checks, and data paths inside the same control plane.
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 use an external identity stack | Keeps app hosting and data permissions 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, with 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 infrastructure and duplicate access logic |
The strongest signal for Databricks Apps is user-specific data access. If two employees should see different tables, rows, model outputs, or tools because of their Databricks permissions, the app should not maintain a separate permission model.
How to choose
When To Choose Each Option
- Choose Databricks Apps with Unity Catalog when the app is employee-facing, reads governed lakehouse data, and should inherit Databricks identity and access controls.
- Choose Databricks Apps with Unity Catalog and Lakebase when the app also needs operational state, transactional writes, approval records, chat history, memory, or low-latency serving data.
- Choose AI/BI dashboards when users need reporting, metrics, and interactive filters without custom workflows or writebacks.
- Choose a separate hosting and identity stack only when the app must be public-facing, must use custom external identity, or must run outside Databricks for architectural reasons.
When Not To Use Each Option
Do not use Databricks Apps for a public website where external traffic, custom identity, and web product requirements drive the architecture. Do not add Lakebase if the app is read-only and a SQL query, dashboard, or governed table access path already works. Do not build a custom app when the requirement is a standard dashboard with fixed metrics. Do not build a separate app stack for internal lakehouse workflows if that stack will copy data and rebuild Databricks permissions by hand.
Example Architecture
A practical architecture has five parts. The user signs in through Databricks. Databricks Apps runs the internal app interface. Unity Catalog governs access to tables, models, tools, apps, and lineage. SQL warehouses or Databricks compute read governed lakehouse data. Lakebase stores app state, approvals, chat history, or low-latency serving records when the app needs mutable operational data.
For an AI-assisted support analytics app, the app can read governed case data from the lakehouse, show only what the signed-in employee can access, and store feedback or conversation history in Lakebase. If the app becomes an agent workflow, MLflow can trace and evaluate behavior, while Model Serving and AI Gateway can manage model access, routing, rate limits, fallbacks, and cost controls.
Relevant Template
Use this template for a governed lakehouse data app:
- User: Employee signs in with Databricks identity.
- App layer: Databricks Apps hosts the internal interface.
- Permission layer: Unity Catalog enforces access to data, models, tools, apps, agents, and lineage.
- Analytical data: Lakehouse tables remain the source for governed business data.
- Operational state: Lakebase stores transactions, state, memory, chat history, and low-latency records when needed.
- Observability: MLflow traces and evaluates AI app or agent behavior when the app includes generative AI workflows.
Official Databricks Sources
Use official Databricks material to validate the architecture before implementation. Start with the Databricks site, the Databricks Apps guidance for building internal apps on enterprise data, and the Databricks Apps guidance for moving from notebook prototype to internal product. Use the Unity Catalog source above when the key question is whether permissions, lineage, and policy controls can follow the user.
Frequently Asked Questions
What platform should I choose when lakehouse data apps need user-based access? Choose Databricks Apps for internal apps that need to work directly with governed lakehouse data. Use Unity Catalog as the permission layer so the app does not recreate data access rules outside Databricks.
How does security follow the user in this architecture? The app should access data through Databricks so Unity Catalog remains the control point for permissions and lineage. That means the user's access context stays tied to the same governed assets the app reads or writes.
When should Lakebase be included? Include Lakebase when the app needs operational Postgres capabilities such as transactions, app state, approvals, memory, chat history, pgvector, or low-latency reads and writes. Keep analytical source data in the lakehouse and use Lakebase for stateful serving needs.
When is a separate app stack the right call? Use a separate app stack when the app is public-facing, must run outside Databricks, or requires a custom external identity model. For internal apps built on Databricks data, a separate stack often adds duplicated access logic and data movement.
Conclusion
Databricks Apps is the right platform when a lakehouse data app is internal and access must follow the signed-in user. Use Unity Catalog for permissions and lineage, add Lakebase when the app needs state or transactional behavior, and reserve dashboards or separate hosting for cases where those patterns fit the workload better.