Global Data Center Hubs: From Metro Shortlist to Actual Site

Define the job before choosing a hub

Start with the deployment being considered: customer-owned equipment in colocation, a provider-operated GPU service, or another arrangement with a defined owner for each layer. A market with a substantial colocation footprint does not automatically offer the GPU model, software stack or tenancy arrangement a cloud buyer needs. A cloud region name is also insufficient to release a physical installation package.

Write down the workloads, data dependencies, users and required delivery window. Identify which conditions are mandatory and who can accept a proposed exception. If the application owner requires a specific relationship to an existing system, preserve that requirement through the comparison instead of replacing it with a general statement that the metro is well connected.

This guide uses six operator-documented examples to show how to read a shortlist. They are selected examples across several regions, not a ranking of the largest markets, an exhaustive directory or a claim that Leviathan has teams stationed in them.

Read six market examples at the right geographic level

Equinix's Washington, D.C. page lists sites in Ashburn and Manassas; its Frankfurt page distinguishes central and campus locations. Digital Realty's Tokyo listing includes Mitaka in Tokyo and Inzai in Chiba, while its Singapore listing separates Jurong East and Loyang facilities. Equinix's Brazil listing identifies SP2 in Barueri and SP3 in Santana de Parnaíba, in São Paulo state. These examples make the exact facility identifier more useful than a metro label alone.

London adds a different distinction: Colt DCS describes London 6, 7 and 8 at its Hayes campus as planned development. A planned building should remain a prospective option until its relevant phase and customer delivery conditions are confirmed. None of the sources below establishes an allocation for the reader's project.

References: [E1][E2][D1][D2][E3][C1]

Make hard constraints visible before scoring preferences

A weighted score can hide a fundamental mismatch. Keep mandatory conditions visible before comparing preferences such as convenience or expansion options. An unconfirmed requirement should remain open; it should not receive a neutral score that makes the option look equivalent to a confirmed one.

Use a compact evidence record for each candidate facility. Describe the required condition, the evidence received, its date and applicable scope, and the person who can accept it. A provider's general capability statement and a customer-specific approved proposal answer different questions. Neither should be silently substituted for the other.

Compare power at the customer delivery boundary

A campus power headline and the power offered to one customer describe different boundaries. The first may describe a development or an aggregate facility; it does not identify the load allocated to a specific cabinet, deployment or equipment configuration. A useful site comparison keeps the proposed customer allocation and its applicable phase, unit and conditions beside the original campus statement. Do not rank an option as adequate merely because its larger number belongs to a larger boundary.

Equinix provides a concrete terminology example. Its colocation documentation describes a deployment-wide customer-load limit called a Draw Cap, measured in kVA, and separately describes the circuits delivering power to cabinets. This distinguishes an agreed load boundary from physical supply infrastructure. The site's actual provider offer and applicable conditions must identify both. Redundant circuit labels are not permission to add their ratings and call the result the customer's permitted load. This is a named provider example, not a rule for every contract or an electrical design for this project.

Keep the original unit with each requirement and return. A kW equipment requirement and a kVA offer are not the same field with different spelling. The responsible equipment and electrical/facility owners must supply the applicable comparison basis; the buyer should not invent a power factor or conversion to close the gap. Likewise, a power-supply rating, actual equipment demand, contractual allocation and measured operating value have different meanings. Retain the meaning, configuration, equipment state and source rather than substituting one for another.

For each candidate, obtain a return against the same identified equipment set, installation phase and required window. Ask the provider and qualified technical owners to identify the applicable customer power allocation, supply/interface documentation, unresolved facility conditions and their separate dispositions. Keep cooling and physical delivery dependencies visible even when a power answer is returned. A confirmed commercial allocation would not, by itself, approve the actual electrical connection, equipment placement or completed installation.

References: [P1]

Separate present sites from future capacity

Use separate fields for the facility's described status and the status of the capacity being offered. An operating campus can have an expansion that is still planned. A future phase can also appear in the same operator portfolio as operating buildings. Keep the phase identifier beside every quoted delivery statement.

Digital Realty's August 24, 2026 announcement describes a provisional capacity allocation for a new Jurong Island development. That announcement is different evidence from the operator's Singapore facility listing. It is not proof that the new development can accept a customer's equipment now. The same distinction applies to Colt's planned Hayes buildings.

When sources disagree or an older announcement gives a different target, retain the discrepancy and ask the responsible provider for the current applicable position. Do not choose the most convenient date or add a planned quantity to a figure for operating supply. The decision record needs the condition that actually governs the proposed deployment.

References: [D3][D2][C1]

Connect the capacity claim to the specific installation

A metro total, campus headline and proposed customer allocation are different quantities. Even a correctly quoted power figure does not identify the approved rack positions, supported equipment arrangement or service access for a particular installation. Keep the original unit, measurement boundary, phase and source attached to every number that enters the project record.

For a physical deployment, carry the exact system configuration into the facility review. A change from one enclosure to another can affect interfaces and access even when the GPU family name stays the same. Return unresolved compatibility questions to the responsible OEM and facility owners rather than assuming that a market described as suitable for AI has approved every GPU server.

For provider-operated compute, ask a separate availability question about the requested service, location and time window. A physical-building listing is not an account quota, a reservation or a promise of usable GPU instances. Keep that procurement path separate from an installation brief for customer-owned equipment.

Compare network endpoints rather than city reputation

Describe the relationships the deployment needs: the existing data location, the application users, the receiving environment and the relevant provider endpoints. Then identify the proposed connection at the actual candidate building. A cloud logo on a metro page does not, on its own, describe the route, ordered service or customer acceptance conditions.

Keep requirements and observations separate. A statement that a workload needs a particular network outcome is not evidence that a candidate meets it. Ask the network owner to define the applicable evidence and acceptance conditions; this article supplies no universal latency threshold or test method.

The geographic examples above also matter to logistics. A project record saying only Tokyo or São Paulo can conceal a different municipality or campus from the one the team expects. Use the provider's exact site identifier throughout the endpoint, receiving and access records so the project is discussing one location consistently.

Trace the fiber offer through the customer handoff

Fiber available in the metro is not a complete connection description. Name the actual source and destination facilities, service type, physical demarcation points and the customer equipment endpoints. Then identify which party supplies each intervening segment and which proposed phase and service window the return covers. A provider's presence in the building or an attractive network map cannot fill an unnamed endpoint or establish permission for work on provider-controlled infrastructure.

Equinix's Cross Connect documentation describes delivery through an approved demarcation point and distinguishes patching from that point to the customer's equipment. Its Fiber Connect documentation separately states that its published measurements are panel-to-panel and exclude the customer cage-to-panel connection. These examples show why a service description and an entire equipment-to-equipment path can cover different scopes. They do not prescribe a customer cabling method, make another provider use the same boundary or prove that any service is currently available.

Carry the complete intended relationship into the physical deployment brief. An ordered provider segment, customer-side patching, equipment interface and network/service acceptance need their own named scope and accountable return. Keep any unassigned segment explicit rather than treating an installed panel or a received cross-connect ticket as completion of every downstream task. A defined pair of endpoints also does not establish path diversity, latency, supported optics, configured service or workload performance.

Fictional EX-SITE149 compares options A and B for one identified equipment set and required deployment window. The four records below deliberately use different evidence boundaries. They do not score, select or approve either site. Each unresolved field goes back to the owner who can supply the actual basis; the next comparison uses those returned facts with the same equipment, phase and window. Only afterward can the appointed parties decide the facility and the separately authorized installation package.

References: [X1][X2]

Work through a shortlist discrepancy

Consider a hypothetical two-option review. Option A has a proposed location in an operating building, but the customer's network dependency is unresolved. Option B has an attractive future expansion description, but no project-specific allocation or accepted delivery window. Neither is ready for a final commitment merely because the broader metro is established.

The coordinator records a named network owner and required evidence for Option A, and a provider delivery owner for Option B. The next review evaluates the answers rather than refreshing a generic market score. If the provider changes a building, phase or configuration, the affected evidence is reviewed again. A previous decision about another location does not automatically transfer.

This example is an original planning scenario, not a description of an actual Leviathan customer. It illustrates a useful output from market research: a short list of decisions that can be closed, with the source and owner required for each one.

Turn the selected site into a local release package

Once a location is selected, preserve the same facility identity in the equipment list, drawings, connection records and installation scope. Identify the receiving and access process, customer-furnished materials, approved workfront, expected work window and accepting owner. A site's selection does not itself authorize an installer to perform every task within it.

For an international program, keep the local document language, original measurement units and dated time-zone reference visible. Assign country-specific commercial, entry/work authorization, shipping, insurance and regulated-work questions to the responsible company and qualified local owners. A shared global template helps retain information, but cannot establish those permissions.

Leviathan's confirmed public description supports U.S. projects subject to scope, site requirements and team availability. International field coverage and local authority must be established separately before being offered. This guide describes market and project planning; it does not announce foreign offices, stationed teams, a hosting service or new electrical, cooling or commissioning capabilities. Identify the appointed equipment/material supplier and delivery responsibilities; a global market guide does not establish country-specific delivery or operating authority.

References: [L1]

Keep the shortlist useful as information changes

Record a checked date and source for each fact, and keep the provider's original terminology with it. When a proposal changes, review the affected facility, phase, equipment or connection evidence instead of treating the entire metro record as current by default. Preserve both the unresolved question and its final disposition so another reviewer can understand why the choice changed.

The useful result is a defensible facility comparison and a clear next action. It need not contain every data center in a country or award a universal best-hub label. Start a physical-scope discussion with the exact site, system list, available drawings and the work being requested; retain separate owners for decisions outside that package.