Deployment Models

When building a data or AI product on Databricks, one of the first architectural decisions is selecting the right deployment model. This choice determines where infrastructure lives, who manages it, and how your customers interact with the platform.

Overview

Model	Description
Partner Hosted (SaaS)	You own and operate the entire Databricks environment. Customers access your product as a service.
Hybrid	You manage the control plane; the data plane runs in the customer's cloud account.
Side Car	Federated pattern using Delta Sharing where you build centrally and deliver assets to customer environments.
Customer Managed	Customer owns everything. You provide software, guidance, or templates.

Comparison

Factor	Partner Hosted	Hybrid	Side Car	Customer Managed
Infrastructure ownership	Partner	Partner (control plane) / Customer (data plane)	Partner & Customer	Customer
Data location	Partner's environment	Customer's environment	Customer's environment	Customer's environment
Operational responsibility	Partner	Partner	Shared	Customer
Customer Databricks account required	No	No	Yes	Yes
Data residency control	Low	High	High	High
Partner control over platform	High	Medium	Medium	None
Implementation complexity	Lower	Medium	Medium	Higher
Customer onboarding effort	Minimal	Moderate	Moderate	Significant

Choosing a Model

When selecting a deployment model, consider:

1. Data residency requirements — Does your customer's data need to stay in their environment?

2. Operational capacity — Do you want to manage infrastructure, or does the customer prefer to?

3. Customer sophistication — Does the customer have a platform team capable of managing Databricks?

4. Regulatory constraints — Are there compliance requirements dictating where data can reside?

5. Scale and economics — Which model provides the best unit economics for your business?

Many partners offer multiple deployment models to serve different customer segments—Partner Hosted for customers seeking simplicity, and Hybrid for enterprise customers with specific data residency or compliance requirements.

Application Architecture

For most Built On Databricks products, you will build an application that sits between your end users and the Databricks platform. A typical application architecture follows a layered system where each layer has clear responsibilities and security boundaries. This architecture ensures that Databricks credentials never reach the client, establishes clear authentication boundaries, and allows the system to scale independently at each layer.

The Five Layers:

1. Client Layer — Browser-based frontend (React, Angular, Vue) that renders UI and makes authenticated API requests
2. Authentication Layer — OAuth 2.0/OIDC integration with your identity provider for user authentication and session management
3. Backend Layer — Server-side API routes that validate sessions, manage authentication tokens, and proxy all Databricks API calls
4. Data Layer — Application database (PostgreSQL, MySQL) storing users, organizations, and encrypted credentials
5. Databricks Platform — Unity Catalog, SQL Warehouses, DBFS, Jobs, and other Databricks services accessed via REST APIs

For a detailed breakdown of each layer's responsibilities, security considerations, and technology recommendations, see the Firefly Analytics architecture documentation.

What's Next

• Partner Hosted (SaaS) — Full control, customers consume as a service
• Hybrid — Partner-managed with customer data plane
• Side Car — Federated pattern using Delta Sharing
• Customer Managed — Customer-owned infrastructure