A tower can put a surprisingly small amount of computing space inside a surprisingly large building, and that arithmetic changes the way capacity should be judged. The proposed Kansas City vertical data center makes the problem unusually clear: roughly 141,000 gross square feet spread across 20 floors, with only two floors dedicated to computing and about 109,000 square feet assigned to mechanical space. The site itself occupies only about 0.23 acres and the proposed structure rises approximately 384 feet, creating an extreme compression of land area into vertical infrastructure. That geometry makes the conventional real-estate vocabulary less useful because gross floor area says little about how much space can actually host IT equipment.

A tower can therefore produce a strong floor-area ratio while delivering a relatively modest computing yield once shafts, plant rooms, structural zones, service routes, and replacement paths enter the calculation. The executive question is not simply how much building exists, but how much of that building remains operationally useful after the infrastructure required to support the compute has been stacked around it. That is where vertical development becomes an engineering optimization problem rather than a simple land-efficiency exercise.

When Square Footage Lies About Capacity

Floor-area ratio measures gross floor area against site area, which makes it useful for planning density but weak as a measure of data center capacity because it does not explain where usable technical space sits within the building. In the Kansas City example, 141,000 gross square feet sounds substantial until approximately 109,000 square feet of that total goes to mechanical space, leaving the two computing floors to carry the actual IT function. That means the gross-area figure describes the size of the building more accurately than the productive capacity of the facility. The 0.23-acre site further sharpens the contrast because the land footprint remains extremely small while the infrastructure supporting compute expands through the full height of the structure.

A better yield metric would connect IT floor area and IT load to the total building burden rather than treating every square foot as equivalent. One practical formulation is usable compute yield, expressed as IT-ready floor area or contracted IT megawatts divided by total gross building area, with a second measure tracking that output against total support infrastructure area. Such a measure would expose whether vertical construction actually improves capacity or simply relocates a large amount of supporting equipment from the ground plane into upper floors. The Kansas City proposal illustrates why this matters: only two of 20 floors would contain computing equipment even though the building carries the structural and operational obligations of the entire tower. Consequently, a development team evaluating a tower should ask how many square feet it must construct, service, reinforce, cool, power, access, and eventually refurbish for every square foot that actually produces IT capacity.

The Riser Is The Data Center Now

A horizontal data center can distribute infrastructure across a broad plane, while a tower has to move power, cooling fluids, communications, exhaust, fire protection, and other services between floors through vertical distribution routes. That makes the riser strategy a capacity constraint rather than a coordination detail. Every major vertical route consumes shaft area, introduces fire-rated penetrations, creates maintenance requirements, and establishes where future distribution can physically expand. The number and alignment of shafts also influence how far branch systems must travel before reaching the compute floors, which affects pressure drop, cable routing, access, and redundancy planning. A tower can therefore have enough gross area on paper while lacking the vertical pathways needed to turn that area into deployable IT capacity.

The critical decision comes before the first rack arrives because riser geometry becomes expensive to change once structure, fire separation, mechanical rooms, and floor plates have hardened around it. Knock-out locations, spare sleeves, shaft dimensions, equipment access, and vertical alignment should reflect credible future loading rather than only the initial equipment schedule. The same principle applies to cooling and electrical distribution: a route sized for today’s two compute floors may become a physical ceiling if later equipment requires larger conductors, additional piping, or different distribution architecture. The resulting constraint is not theoretical; vertical data center design already faces practical challenges because equipment, elevators, crane access, weight, and replacement routes interact with the building’s geometry. 

Weight Lives Where You Least Want It

The structural problem becomes sharper when heavy support equipment must occupy levels above or around sensitive computing floors because the load path then extends through every intervening level before reaching the foundation. Data center floors must account for concentrated, uniform, and rolling loads rather than relying on a single floor-loading number, while high-density racks can place substantial loads onto small contact areas. A loaded cabinet may satisfy an average floor-load calculation and still create a concentrated condition that controls the slab, access-floor assembly, pedestal, beam, column, or connection below it. The structural engineer therefore has to trace the actual load from equipment feet through the floor system and framing rather than treating the data hall as a uniformly loaded rectangle. In a tower, that path becomes especially consequential because equipment positioned several floors above grade transfers its influence through a much larger structural stack.

Vibration adds another dimension because the structure must carry weight without transmitting unacceptable movement from rotating mechanical equipment into sensitive areas. Pumps, fans, chillers, and other mechanical systems can introduce vibration into the building, while structural stiffness and equipment isolation determine how much of that energy reaches adjacent spaces. The location of heavy plant therefore affects more than structural strength; it can influence dynamic behavior, equipment placement, maintenance access, and future reconfiguration. Freight movement creates a separate transient condition because the floor must tolerate equipment while it rolls across the building, not merely after it reaches its final position. For that reason, the deployable capacity of a vertical data center should follow the complete freight path from loading point to final equipment position rather than stopping the analysis at the room entrance.

Service Space Is Not Leftover Space

Service space becomes productive infrastructure when equipment depends on predictable access for inspection, repair, replacement, and expansion. Corridors, lift lobbies, staging areas, equipment transfer zones, and clearances around plant all consume floor area, yet removing them from the plan does not create additional usable capacity because the remaining equipment becomes harder or impossible to service. Vertical facilities intensify this problem because a single freight elevator, transfer zone, or shaft can become a shared dependency for multiple floors. Equipment logistics guidance emphasizes that access, headroom, floor loading, crane paths, and timing need consideration before equipment arrives, because discovering a route constraint during delivery can force building alterations.

The operational cost appears later when replacement work competes with live infrastructure for the same physical route. A tower that requires equipment to pass through active areas, share constrained elevators, or coordinate external lifting operations can preserve theoretical capacity while reducing the speed at which that capacity can be maintained or upgraded. Freight elevator dimensions matter because a component that cannot fit through the intended route is not merely inconvenient; it can become a replacement strategy problem. Service areas should therefore enter the capacity model as an explicit operating requirement, with their dimensions tied to the largest credible equipment that the building must receive and remove. This approach turns circulation from an architectural residual into a measurable part of lifecycle capacity.

Vertical Doesn’t Shrink The Footprint, It Stacks It

Vertical construction can reduce the amount of land occupied at grade, but it does not eliminate the infrastructure required to deliver computing capacity; it redistributes that infrastructure through height. The Kansas City proposal captures the inversion clearly, with approximately 109,000 square feet devoted to mechanical space inside a 141,000-square-foot building while only two of 20 floors carry computing equipment. The small 0.23-acre site therefore tells only one part of the development story because the actual engineering burden occupies structure, shafts, plant floors, circulation zones, elevators, and equipment routes extending hundreds of feet upward. For capital planning, the relevant question becomes how much support infrastructure must be stacked to make each unit of IT capacity viable. That measure can reveal a very different efficiency profile from the one suggested by land coverage or gross floor area alone.

The stronger vertical design is not necessarily the one that reaches the greatest height, but the one that keeps the support ratio, structural burden, riser demand, and service requirements aligned with the amount of compute the tower can actually deliver. A building with fewer floors may outperform a taller alternative if it removes unnecessary vertical transfers, shortens replacement paths, simplifies distribution, and leaves more of its constructed area available for productive IT use. That changes how developers should evaluate sites, because the winning geometry may emerge from the load path, the riser diagram, and the freight route before it appears in the architectural massing. In a vertical data center, land efficiency is real, but it becomes meaningful only when the height added to save land does not consume the operational capacity that the project was built to create.