Applications and workloads
Creates demand through AI assistants, analytics, model training, inference, search, automation, and enterprise software.
The AI infrastructure demand stack.
Follow demand from applications through Databricks-like platforms, cloud regions, facility developers, and the physical systems that reach a community.
The AI infrastructure demand stack turns demand for a digital service into demand for computing equipment and physical data center capacity.
Applications create workloads. Platforms organize them. Cloud providers supply regional compute. Developers and operators deliver buildings, power, cooling, and connectivity. The arrows describe dependencies—not one universal ownership chain or contract.
Compare neocloud rolesThe five layers.
The arrows describe dependencies, not one universal ownership chain. A company can participate in several layers, while land, buildings, utility service, servers, software, and customer contracts remain under different control.
Data and AI platforms
Organizes data, models, governance, jobs, and requests for compute.
Cloud and compute providers
Supplies regional virtual machines, accelerators, storage, networking, and managed services.
Developers and facility operators
Secures sites and power, finances and builds facilities, leases capacity, operates buildings, and provides interconnection.
Physical facilities and local systems
Houses servers and connects them to electricity, cooling, water, fiber, backup systems, transportation, emergency response, and local oversight.
| Layer | What it does | Typical participants | What it does not prove |
|---|---|---|---|
| LayerApplications and workloads | What it doesCreates demand through AI assistants, analytics, model training, inference, search, automation, and enterprise software. | Typical participantsBusinesses, public agencies, model developers, software companies, and end users. | What it does not proveOne application does not necessarily map cleanly to one facility or region. |
| LayerData and AI platforms | What it doesOrganizes data, models, governance, jobs, and requests for compute. | Typical participantsDatabricks and other data, machine-learning, and AI platforms. | What it does not proveThe platform does not necessarily own the physical data center serving every workload. |
| LayerCloud and compute providers | What it doesSupplies regional virtual machines, accelerators, storage, networking, and managed services. | Typical participantsAWS, Microsoft Azure, Google Cloud, neoclouds, and enterprise private clouds. | What it does not proveA cloud region is not necessarily one building or entirely provider-owned. |
| LayerDevelopers and facility operators | What it doesSecures sites and power, finances and builds facilities, leases capacity, operates buildings, and provides interconnection. | Typical participantsHyperscalers, colocation operators, build-to-suit developers, infrastructure funds, and project companies. | What it does not proveThe developer is not necessarily the ultimate compute customer or the party controlling the workload. |
| LayerPhysical facilities and local systems | What it doesHouses servers and connects them to electricity, cooling, water, fiber, backup systems, transportation, emergency response, and local oversight. | Typical participantsData center operators, utilities, contractors, municipalities, and water and wastewater providers. | What it does not proveA useful upstream application does not establish that the physical project is responsible. |
Databricks sits between applications and cloud infrastructure.
Databricks is a useful example because its platform, account structure, compute resources, cloud provider, and physical facility can be controlled by different parties.
The control plane manages the platform.
Databricks describes the control plane as the management layer for the workspace, notebooks, configuration, and clusters. It coordinates the service but is distinct from the compute plane where data processing occurs.
Classic compute can run in the customer’s cloud account.
In a classic AWS deployment, Databricks compute resources are created inside the customer’s AWS account and virtual network. The customer, platform, and cloud provider therefore hold different responsibilities within the same workload.
Serverless compute is platform-managed within a cloud region.
For serverless deployments, compute runs in a Databricks-managed account in the selected cloud region. That can create substantial regional infrastructure demand without putting the Databricks name on the building that ultimately houses the equipment.
Cloud regions represent real facilities.
Regional service labels influence where capacity must exist, but they do not identify one building. Regions can span several zones, facilities, and ownership arrangements.
AWS regions contain independent availability zones.
AWS defines a Region as a separate geographic area and an Availability Zone as one or more discrete data centers with independent power, networking, and connectivity.
Azure regions connect one or more data centers.
Microsoft says an Azure region contains one or more data centers connected by a high-capacity network. Many regions include physically separated availability zones with independent infrastructure.
Google Cloud can use owned or leased facilities.
Google describes regions and zones as logical abstractions of physical resources and states that underlying data centers can be owned by Google or leased from third-party providers.
Specialists deliver the physical capacity.
Cloud and AI companies can combine owned campuses with leased colocation, build-to-suit facilities, and interconnection hubs. The party announcing a service may not own the land, building, or utility agreement.
Colocation leases ready capacity.
A provider can place equipment inside a shared or dedicated facility where the operator supplies the building, power, cooling, security, connectivity, and operations.
Build-to-suit delivers a customized facility.
A specialist developer can finance and construct a powered building or campus around one major customer’s requirements while the customer installs or operates the computing systems.
Interconnection links the layers.
Carrier-neutral facilities and cloud on-ramps connect enterprises, networks, platforms, cloud regions, and other data centers without requiring every participant to occupy the same building.
How demand reaches a community.
The path is commercial as well as technical. Each handoff changes which party controls the next decision—and which evidence a public reviewer should request.
A workload grows.
More users, larger models, new enterprise deployments, or additional inference creates demand for compute, storage, and network capacity.
A platform or customer requests resources.
Databricks, another platform, or the application operator places workloads in a selected cloud, account structure, and region.
A provider commits capacity.
The cloud or compute provider decides whether to use inventory, install equipment, lease capacity, or support new development.
A market and site are selected.
Power, fiber, latency, data residency, land, permitting, tax conditions, water, climate, and construction schedules shape the location.
Infrastructure is delivered.
Utilities, developers, contractors, suppliers, and operators build or expand substations, data halls, cooling, backup systems, fiber, and supporting infrastructure.
Operations create measurable local effects.
Electricity and water use, sound, traffic, emergency procedures, emissions, jobs, tax revenue, and infrastructure costs occur at the facility—not in the application interface.
What changes the answer.
The same digital service can produce different infrastructure outcomes depending on workload, deployment model, region, ownership, efficiency, and expansion rights.
Training or inference
Large training clusters can favor concentrated high-density capacity; inference can be distributed closer to users and existing cloud regions.
Classic or serverless
Compute may run in the customer’s cloud account or in platform-managed infrastructure, changing control without removing physical resource demand.
Cloud region and data residency
Latency, regulation, resilience, and data-location requirements affect where compute can be placed.
Owned, leased, or build-to-suit
Ownership and operating responsibility can differ even when the digital service appears identical to its user.
Efficiency
Better software, chips, utilization, cooling, and facility design can reduce the infrastructure required for the same level of digital service.
Full buildout
The first building or utility phase may represent only part of the contractual expansion rights or ultimate campus plan.
Map responsibility at every layer.
A recognizable application, platform, or cloud company can explain why demand exists. It cannot replace site-level evidence about capacity, infrastructure, costs, operations, and long-term obligations.
| Ask the developer | Request this evidence | A credible response contains |
|---|---|---|
| Ask the developerWhat supports the project? | Request this evidenceExpected workload, customer mix, training and inference assumptions, and confidentiality limits. | A credible response containsA bounded description of demand that connects workload type to density, networking, cooling, and realistic growth patterns. |
| Ask the developerWho controls each layer? | Request this evidenceOrganization chart covering land, buildings, utility account, tenant, operator, servers, platform, and customer contract. | A credible response containsLegal names, contract roles, control boundaries, guarantees, transfer rights, and the party responsible for corrective action. |
| Ask the developerWhat capacity is committed? | Request this evidenceExecuted agreements, phased load schedule, expansion options, and full-buildout demand. | A credible response containsClear separation of contracted, forecast, reserved, and speculative capacity with dates and expiration conditions. |
| Ask the developerWhich region and resilience model applies? | Request this evidenceCloud-region role, availability-zone relationships, fiber routes, and operational dependencies. | A credible response containsThe facilities and shared systems supporting the service, without treating a cloud region as one building. |
| Ask the developerWho pays for supporting infrastructure? | Request this evidenceInterconnection studies, upgrade estimates, cost-allocation terms, and water, wastewater, fiber, and road plans. | A credible response containsNamed responsibility for capital, operations, maintenance, contingencies, schedule risk, and long-term community costs. |
| Ask the developerWho reports actual performance? | Request this evidenceNamed reporting party, meters, methods, schedule, public metrics, and corrective process. | A credible response containsFacility-level energy, water, sound, emissions, reliability, employment, and fiscal results compared with the approval record. |
| Ask the developerWhat happens if the contract changes? | Request this evidenceLease protections, guarantees, reuse plan, decommissioning obligations, and financial security. | A credible response containsA durable plan for buildings and infrastructure that may outlast fast-changing technology customers and services. |
The Good Neighbor Data standard.
A credible review maps the complete chain from workload to platform, cloud region, capacity agreement, land, power, building, equipment, operator, and long-term obligations. Give every material commitment a named responsible party, measurable standard, reporting schedule, and corrective process. Continue with the grid-impact guide and planning checklist.
Frequently asked questions.
Does Databricks own data centers?
Databricks manages platform infrastructure and, for serverless deployments, manages compute within its cloud account. Classic compute can run in the customer’s cloud account. Neither arrangement means every workload runs in a Databricks-owned building; underlying cloud capacity can use provider-owned or leased facilities.
Does one AI application run in one data center?
Usually not. Applications can use several services, regions, zones, and providers, and workloads can move or scale over time. Do not assign one application’s demand to one building without project-specific evidence.
Are cloud regions the same as data centers?
No. Regions are geographic service areas containing one or more zones and physical facilities. A zone can include one or more data centers, and providers may use both owned and leased facilities.
Who should a community hold accountable?
Each party should be accountable for the obligations it controls. Permit and agreement terms should name who controls construction, load commitments, equipment, cooling, sound, reporting, property obligations, and corrective action.
Sources
Databricks — Platform architectureControl-plane and compute-plane roles.Databricks on AWS — High-level architectureClassic and serverless account structures, regional placement, storage, and compute responsibility.AWS — Regions and Availability ZonesRegion, availability-zone, and discrete-data-center definitions.Microsoft Azure — RegionsRegions, data centers, networks, data residency, and availability-zone relationships.Google Cloud — Geography and regionsRegions, zones, physical resources, and owned-versus-leased data centers.Digital Realty — Data centersColocation, interconnection, cloud on-ramps, and AI-ready facility services.Digital Realty — Build-to-suitCustomized third-party facility delivery.International Energy Agency — Energy demand from AIPhysical components, demand uncertainty, efficiency, and geographically concentrated grid effects.National Association of CountiesLocal land-use, infrastructure, water, power, and long-term oversight considerations.Pennsylvania Data Center Planning ToolkitMunicipal coordination with utilities and infrastructure providers.
Last updated July 2026. Review technical and policy information for the specific site, jurisdiction, utility territory, and operating plan.