how do i fit an internal app platform into my existing data stack

Summary

• An internal app platform fits best on top of the stack you already have. Databricks Apps run natively on Databricks as the interactive layer above the governed lakehouse, reusing your data, identity, and permissions instead of a separate app server.
• Apps sit between read-only dashboards and open-ended notebooks: the place for custom, read-write interfaces (forms, approvals, file uploads, chat over your data and models) that dashboards cannot provide.
• Because an app runs under a service principal and inherits Unity Catalog permissions, adding one opens no new security hole: masked data stays masked and restricted tables stay restricted, managed in one place.
• Databricks Apps is generally available across AWS, Azure, and GCP. You build in Python or JavaScript frameworks, connect through SQL warehouses, Model Serving, Genie, and Lakebase, and deploy with the CLI and Declarative Automation Bundles.

how do i fit an internal app platform into my existing data stack

An internal app platform fits best when it sits on top of the data stack you already have, not beside it. Databricks Apps run natively on the Databricks platform as the interactive layer above your governed lakehouse: they reuse the same data, identity, and permissions you already manage, so you do not stand up a separate app server, copy data into it, or wire up a new login system. Think of them as the layer between read-only dashboards and open-ended notebooks, the place for the custom, read-write interfaces those two cannot cover. Because an app inherits the platform's governance, adding one does not open a new hole in your security model.

Where an internal app platform sits

Dashboards answer standard reporting and Genie answers ad-hoc questions, but some jobs need a real UI: a form, an approval workflow, a file upload, an interactive tool, or a chat interface over your data and models. Dashboards are read-only, so the moment users need to write back, whether that is kicking off a pipeline, changing a record, or triggering an ML run, you need an application. An internal app platform gives you that surface without leaving the data platform, which is what keeps governance and data access consistent.

What to look for in an internal app platform

Capability	Why it matters
Governance reuse	The app should honor your existing data permissions automatically. Masked columns stay masked and restricted tables stay restricted, with no second access model to maintain.
Identity and SSO	Users sign in with the identity they already have. A separate auth system is a security and maintenance burden.
Direct data connectivity	Query governed tables in place, without exporting data or managing connection strings.
AI and model access	Call model endpoints and natural-language query tools from the app, so AI features do not need a separate service.
Framework choice	Support for the Python and JavaScript frameworks your developers already use, so you are not forced into one toolkit.
Deployment and CI/CD	Version-controlled, automatable deploys that fit your existing release process.
Managed runtime	The platform runs and scales the app, so there is no container fleet to operate.

How Databricks Apps fit

Databricks Apps run as containerized workloads on managed serverless compute, so there is no separate infrastructure to provision. What makes them fit an existing stack is how they connect to it:

• Governed data access. An app runs under a service principal and reaches Unity Catalog tables directly, with no connection strings to manage. It respects the access controls already in place, so masked data stays masked and restricted schemas stay restricted.
• Query and AI. Apps query analytical data through SQL warehouses, call Model Serving and Foundation Model API endpoints for inference, and embed Genie and Agent Bricks for natural-language and agentic features.
• App state. Lakebase, the managed Postgres in Databricks, gives an app a place for session state and low-latency operational data.
• Identity. Apps authenticate with OAuth and OIDC and use workspace SSO, so users get in with their existing identity and the app only ever exposes what its principal is allowed to see.
• Frameworks. Build in Python (Streamlit, Dash, FastAPI, Flask, Gradio, Django, Chainlit) or JavaScript (React, Angular, Svelte, Express).
• Deploy. Define the app in an app.yaml file and ship it through the Databricks CLI or UI, with CI/CD via GitHub Actions and Declarative Automation Bundles. Apps can also be distributed through Databricks Marketplace.

Databricks Apps is generally available across AWS, Azure, and GCP. See the Databricks Apps docs, the introduction blog, and Python app hosting on Databricks.

When to build an app, and when not to

Build an app when you need a UI beyond charts and tables, when it needs direct governed access to lakehouse data without ETL, when read-write actions or file uploads are involved, or when you are putting a front end on an agent. Reach for a dashboard or Genie when the need is standard reporting or ad-hoc questions and a simple view would do; an app adds development and upkeep that pays off only when you need the extra capability.
Apps are not the right tool for public, anonymous internet audiences (they require a Databricks identity), for mobile or desktop clients (they are browser-based), or for static content hosting. Knowing those edges keeps the platform aimed at internal, governed, data-backed tools, which is where it fits best.

FAQs

Is Databricks Apps generally available?

Yes. Databricks Apps is generally available across AWS, Azure, and GCP after an earlier public preview.

How does an app access governed data without a new security model?

The app runs under a service principal and inherits Unity Catalog permissions. It can only read what that principal is allowed to read, so masked and restricted data stay protected and you manage access in one place.

Do I need a separate server to run an internal app?

No. Apps run on Databricks-managed serverless compute as containerized workloads, so there is no app server or container fleet for you to operate.

When should I use a dashboard instead of an app?

Use a dashboard or Genie for standard reporting and ad-hoc questions. Choose an app when you need custom interactivity, read-write actions, or a UI over your models that a dashboard cannot provide.