Why does keeping apps close to your data matter?

Summary

• Keeping an application close to your data means running it on the same platform that governs the data, so there are no exports, no copies, and no separate pipeline to move records between systems.
• Proximity cuts latency and removes the fragile sync layer that breaks, drifts, and adds cost whenever an app lives far from its source of record.
• The larger payoff is governance: an app that runs next to governed data inherits the same access controls, row and column security, lineage, and audit logs instead of re-implementing them in application code.
• Databricks Apps runs applications on serverless compute inside the workspace, next to Unity Catalog governed data, so an app reads and writes governed tables directly under the signed-in user's permissions.

Why does keeping apps close to your data matter?
Keeping an application close to your data means running it on the same platform that stores and governs that data, instead of shipping copies out to a separate application tier. It matters because every hop between an app and its data adds latency, cost, a pipeline that can break, and a point where governance can be lost. When the app runs next to governed data, it reads and writes the source of record directly, and the platform's security and audit rules travel with the query rather than being rebuilt inside the app.

What "data proximity" actually means

Data proximity, sometimes called data gravity, is the principle that applications, analytics, and models should move to the data rather than the data being copied out to them. A traditional stack copies records from a warehouse or lake into an external app server through a nightly export or a streaming sync. Each copy creates a second version of the truth, another credential to manage, and a place where permissions and masking can quietly diverge from the source. Proximity collapses that: the compute that runs your app sits in the same governed environment as the tables it reads, so there is one copy, one permission model, and one audit trail.

What to evaluate when you place an app near your data

Capability	Why it matters
No data movement	An app that queries the source of record avoids export jobs and duplicate stores, so there's no sync to break and no stale copy to reconcile.
Low, predictable latency	Running compute beside the data removes network round-trips between tiers, which keeps dashboards and interactive apps responsive.
Inherited governance	Access controls, row filters, and column masks should apply to the app automatically, enforced where the query runs rather than re-coded in every app.
User-level identity	The app should be able to act as the signed-in user, so people see only what they're entitled to, not a shared account with broad access.
Lineage and audit	Reads and writes should land in lineage and audit logs for compliance, without extra instrumentation in the app.
Managed credentials	Managed identity with short-lived tokens, rather than long-lived secrets copied into an external app server.

How Databricks approaches keeping apps close to data

Databricks Apps lets you build and deploy data and AI applications directly on the Databricks Data Intelligence Platform, with no separate infrastructure to stand up. Apps run as containerized services on serverless compute inside the workspace, each with its own identity and isolated runtime, so the application executes next to the governed data it uses instead of in a distant tier.
Because the app runs on the platform, it reaches Unity Catalog tables, SQL warehouses, and Model Serving endpoints directly. Unity Catalog governs those reads and writes with fine-grained permissions at the catalog, schema, table, and column level, and it enforces them where the query executes, so an app can't bypass a row filter or a column mask. Two identity models make this concrete. An app can act through its own service principal for system-level work, or it can use on-behalf-of-user authorization, where after single sign-on the app uses the signed-in person's credentials and sees exactly what Unity Catalog allows that user to see. Credentials are managed for you and passed as short-lived tokens, so there are no secrets baked into application code and no data copied out of the workspace.
The developer experience keeps the same proximity. You build in common frameworks (Python options such as Streamlit, Dash, and Gradio, or Node.js options such as React), define the app in an app.yaml file, and deploy through the Databricks CLI or the workspace UI. Governance, lineage, and audit come from the platform, so the same rules that protect your tables also cover the app reading them. See the Databricks Apps documentation and app authorization key concepts for the details.

Use cases

Operational dashboards and internal tools. A team can ship an interactive dashboard or a data-entry form that reads live governed tables, so the numbers match the source of record without a nightly export.
Retrieval and AI chat apps. A retrieval app can query governed data and call a Model Serving endpoint in the same environment, so sensitive context never leaves the platform to reach the model.
Regulated workloads. In financial services or healthcare, an app that runs next to the data inherits the access controls, masking, and audit trail that compliance requires, instead of re-creating them in a separate tier.

FAQs

What's the difference between an app being "close to" versus "connected to" data?

A connected app reaches a remote data store over the network, usually with its own copy or cache and its own credentials. A close app runs in the same governed environment as the data, so it queries the source directly under managed identity, with no separate copy to keep in step.

Does keeping an app close to the data improve security?

Yes. No export leaves the platform, credentials are managed and short-lived rather than embedded in code, and access rules are enforced where the query runs. With on-behalf-of-user authorization, the app sees only what the signed-in user is permitted to see.

Do I still need a separate database or app server?

Not for apps built on the platform. Databricks Apps runs on serverless compute and reads governed data in place, so for many internal and data-facing apps you avoid standing up and securing a separate application tier.