Shipping a data app on the lakehouse: Databricks Apps in practice

Most internal tools that read lakehouse data are built the same way: stand up a small app somewhere (Retool, a hand-rolled Streamlit deployment, a Flask service on its own host), then wire it up to Databricks with a service-account token and hope nobody rotates credentials at the wrong time. Databricks Apps removes the “somewhere” — it hosts the app inside the workspace itself, running Streamlit, Dash, Gradio, or a custom Flask app, with workspace identity and Unity Catalog access available natively instead of bolted on. Here’s what that’s actually good for, and where it isn’t the right tool.

What’s actually different, not just convenient

Auth is the workspace’s, not a separate login you build. An app deployed on Databricks Apps authenticates users through the workspace’s own identity — OAuth against Databricks accounts — rather than a bespoke login screen and a separate user table to maintain. For an internal tool, that’s not a minor convenience: it’s one fewer identity system to keep in sync with who actually has access to what.

Data access flows through Unity Catalog governance, not a static token. This is the detail worth getting right early, because it determines whether the app’s data access is actually governed or only looks like it is: an app can query as its own service-principal identity, or run queries on behalf of the logged-in viewer, and the choice changes everything. Run as the app’s own identity and every viewer sees whatever that identity can see — UC’s row filters and column masks apply once, at the app level, not per person. Run on behalf of the viewer and UC’s row filters, column masks, and grants apply exactly as they would if that person queried the table directly in a SQL warehouse. For anything with real access-control requirements — an app different teams use to see different slices of the same table — that second mode is the one that actually enforces the governance model you already built in Unity Catalog, rather than reimplementing an approximation of it in application code.

No second infrastructure stack for a purely internal, lakehouse-native tool. A data-quality review UI, an approval workflow that writes back to a Delta table, a lightweight ops dashboard with a form — tools like this traditionally need their own hosting, their own database connection management, and their own deployment pipeline, none of which has anything to do with the tool’s actual job. Databricks Apps collapses that into “the app lives where the data already lives,” which is a genuine reduction in what has to be operated, not just a nicer developer experience.

Where it fits and where it doesn’t

The sweet spot is internal, lakehouse-native tools: data-quality review and approval UIs, ops dashboards with write-back to governed tables, lightweight self-service tools for teams that already work inside Databricks. If the tool’s entire job is reading and writing Unity Catalog data with per-user permissions that should already exist, building it as a Databricks App means the governance model you built for SQL access carries straight through to the app, instead of being re-specified in a second system.

It’s a weaker fit once a tool needs to integrate many systems that aren’t Databricks — a support tool pulling from a CRM, a ticketing system, and three SaaS APIs alongside the lakehouse — where an integration-first platform like Retool’s breadth of prebuilt connectors is doing real work that a lakehouse-native app framework isn’t built for. It’s also not the right choice for high-traffic, customer-facing applications: it’s built for internal tooling with workspace-scoped auth, not a public app needing its own scaling and deployment pipeline outside the workspace boundary.

The practical takeaway

Don’t default to “everything internal is a Retool app” or “everything on Databricks should be a Databricks App” — ask what the tool is actually integrating. Pure lakehouse read/write with governance that should mirror Unity Catalog exactly is the case Databricks Apps was built for, and getting the run-as-viewer-versus-run-as-service-principal decision right on day one saves a governance retrofit later. Multi-system internal tools still belong on a platform built for breadth of integration — which is a large part of why we run both practices.

Zephico is a Databricks Consulting Partner and also builds Retool and internal-tools projects — we help clients pick the right one for a given tool rather than defaulting to whichever we built last. If you’re weighing where a new internal tool should live, talk to us.