Building Better Apps: Architecture Best Practices and Common Patterns on Databricks Apps

Rather than tuning each app in isolation, teams should standardize on these fundamentals: match compute to the query shape, default to on-behalf-of authorization, architect agents as one component in a larger system, and profile the stack before scaling compute.

Choose compute by query shape, not by habit

Databricks offers complementary engines with different strengths. Lakebase, the Postgres-based OLTP service, is ideal for point lookups, UI state, fast reads and writes, user sessions, and high concurrency. Databricks SQL warehouses on the Lakehouse are built for OLAP, such as large scans, aggregations, and analytical joins.

Pick the engine by workload. Use Lakebase for snappy UI interactions and transactional lists or forms. Use Databricks SQL for dashboards and historical analysis. When you need both, Databricks SQL can reference Lakebase tables through Unity Catalog so you can join OLTP and OLAP data in one query, without data movement.

Enforce user identity with on-behalf-of authorization

Relying on an app's service principal for all access might work during prototyping, but it collapses the audit trail and ignores Unity Catalog policies. Enterprises need to answer who accessed PII, which app triggered an action, and whether former users still have reach.

Enable on-behalf-of (OBO) authorization as the default for user-specific data paths. The Databricks proxy injects a user access token that downstream calls can use to enforce Unity Catalog permissions, including row-level security and column masks. Combine patterns pragmatically, using the service principal for shared concerns like background jobs or application state, and OBO whenever users should see different data, including when users interact with Genie.

Design agents as part of a system, and build for async

Agents are powerful, but they are only one component of a robust application. Databricks makes it straightforward to call hosted foundation models via Model Serving and to route external models through the AI Gateway for guardrails and observability. Unity Catalog connections can be registered once and reused across agents to avoid scattering credentials.

Write agent code asynchronously so IO-bound calls to model endpoints do not block workers. Propagate OBO headers to tool calls, Genie, and model requests so agents cannot exceed user permissions. To speed delivery, consider the MLflow agent server, which handles streaming responses and common serving boilerplate, and AppKit's prebuilt React components for agent and Genie UIs.

Profile end to end before scaling compute

Performance problems rarely disappear by making the app bigger. Databricks Apps supports vertical scaling and, in gated beta, horizontal scaling behind a load balancer. Both can help, but only after you identify the true bottleneck. Start from the browser and trace back through the app and warehouses, then scale the layer that is actually slow.

Proven wins include caching static assets from Unity Catalog volumes on local disk or in memory, using connection pools for Lakebase instead of opening a new connection per query, and running independent Databricks SQL queries in parallel rather than sequentially. Framework choice matters as well. Strongly typed, async-friendly stacks make it easier to write code that scales, and some frameworks require specific worker configurations to use all available cores.

Turn prototypes into production by committing to four principles

Teams that consistently match engines to workloads, enforce user identity, architect agents deliberately, and profile before scaling move beyond brittle demos. These choices compound, producing Databricks Apps that are fast, auditable, and resilient under real enterprise load.