Data center power density and capacity planning field guide

Power density and capacity planning, and why a live hall needs both

Data center power density and capacity planning are the discipline of deciding how many kilowatts each rack, row, and room is allowed to draw, then tracking the power, cooling, and space you have against what is committed. Power density is the kilowatts per rack. Capacity planning is the bookkeeping that keeps the room from running out of any one of those three before the others, and from stranding the headroom you paid to install.

The reason it gets its own discipline is that a live hall does not fail gracefully when it runs out of room. It trips a breaker, it cooks a rack, or it tells a customer there is nowhere to put the next forty servers in a building that looks half empty. Every one of those is a planning miss, not an equipment fault.

This guide covers the kW-per-rack number, the three capacities and how stranding happens, why you plan on measured load instead of nameplate, and how redundancy cuts the usable number below the installed one. The rack PDU types guide covers the strip that lands the power at the cabinet, and the thermal envelope guide covers the cooling target the density has to live inside. This is the layer that sizes both.

What is data center power density?

Data center power density is the electrical load concentrated in a given footprint, stated most often as kilowatts per rack, and sometimes per row, per cabinet, or per square foot of white space. The kW-per-rack figure is the one the whole design hangs on, because it sets the circuit to the cabinet, the cooling at the aisle, and how many racks fit before a capacity runs out.

The number has climbed, and it keeps climbing. A general-purpose enterprise rack a decade or so back sat in the single digits, commonly around 3 to 5 kW, and plenty of legacy halls were built around that. Mainstream racks today land closer to 10 to 20 kW, which is roughly where air cooling starts to strain. AI and GPU racks have broken the scale entirely, drawing 50 to 100 kW and well beyond, with the densest current builds past 100 kW in a single cabinet.

Treat every one of those figures as a moving snapshot, not a constant. The direction is the only thing that holds steady: density is rising, faster than most rooms were designed for. Size to the actual gear and the project's growth plan, and hedge the kW number to what the design and the measured load say, because the rack you plan today is denser than the one the building was built for.

The three capacities: power, cooling, and space

A data center has three capacities, and you run out of whichever one fails first. Power is the kilowatts the electrical chain can deliver, from the utility feed through the UPS and the floor PDU to the breaker at the rack. Cooling is the kilowatts of heat the mechanical plant can remove. Space is the physical floor and rack units the gear occupies. The site's real capacity is set by the most restrictive of the three, not by the one you have the most of.

The mistake is planning each in its own spreadsheet. A hall can have empty floor tiles, open rack units, and spare breakers, and still be full, because the cooling plant is maxed out. That room is out of capacity even though it looks half empty to anyone walking the floor.

Which one binds first has shifted with density. When racks drew a few kW, space usually ran out first and you filled the floor. Now power and cooling almost always bind before space, because a dense rack eats kilowatts and heat far faster than it eats floor. The job is to balance the three so you are not stranding one to chase another. Find the weakest link, because that is the one that decides how full the room can actually get.

What is stranded capacity?

Stranded capacity is power, cooling, or space you paid to install but cannot use, because a different capacity or a piece of distribution gear caps it first. The utility brought in the megawatts, the bill is being paid on them, and a breaker, a PDU, a cooling limit, or a redundancy rule means part of that power will never reach a server. It is money sitting on the floor doing nothing.

Stranding has a dozen everyday causes. A rack with spare breaker headroom but no cooling left in its aisle. A floor PDU loaded on two phases and idle on the third. Cabinets filled to half their power because the operator guessed high on nameplate. A 2N feed where each side runs at 40 percent so it can carry the other side on a failure, which is redundancy doing its job but also stranding capacity by design.

Stranded capacity is the quiet, expensive failure of capacity planning, and it hides because nothing trips and nothing overheats. The room just fills up slower than the install said it should, and somebody orders the next building years before they had to. Finding it takes measured data per rack, per phase, and per aisle, which is exactly what a capacity model and metered distribution are for. Every kilowatt you unstrand is a kilowatt you do not have to build.

Should you plan on nameplate or actual power?

Plan on the measured draw, not the nameplate. The nameplate on a power supply is the maximum the device could ever pull under a worst-case load with everything spinning, and real equipment almost never runs there. Actual draw commonly lands somewhere between roughly 20 and 85 percent of the nameplate depending on the workload, so a server with a 1,200 VA nameplate might pull 400 to 700 W in service. Budget capacity on the nameplate and you will strand half your room.

The old fix was to derate the nameplate by a flat factor, often planning to something like 50 to 75 percent of it. That is better than using the raw nameplate, but it is still a guess, and the guess is wrong in both directions across a mixed floor. Some gear runs hotter than the derate, some far cooler, and the average hides both.

The real answer is to meter. Put a number on what each rack and each circuit actually draws, then plan on that number with a margin for growth and peaks. The rack PDU types guide covers the metered and intelligent strips that read per-outlet and per-inlet load, and a branch-circuit monitor or EPMS reads it upstream. Derate the nameplate only until you have the meter. After that, plan on the real load, because the meter does not guess.

The breaker and the 80 percent continuous rule

The breaker at the rack and on the branch is not usable to its stamped number. The NEC and UL convention treats a load running three hours or more as continuous and limits it to 80 percent of the breaker rating, so a 30 A circuit holds about 24 A of continuous IT load and a 20 A branch holds 16 A. IT load is continuous by nature, which means the 80 percent figure is the working ceiling and the nameplate amperage is just the ceiling above it. Confirm it against the manufacturer's listing and the adopted code.

This derate stacks on top of the nameplate-versus-actual gap, and the two together are why a rack's usable kilowatts are well under what the circuit's headline number suggests. People size the cabinet to the breaker, load to it, and trip on a hot afternoon when the gear comes in heavier than the schedule said.

On an A and B rack the derate goes further, because each side has to hold the whole rack when the other side drops. The rack PDU types guide works the strip-level and per-phase budget in detail. The short version for capacity planning: never plan a rack to its breaker. Plan it to the continuous limit, then to the failover budget under it.

What can a rack actually draw?

Stack the derates and you see why a circuit's headline number overstates what a rack can hold. Take a rack on a 208 V three-phase, 30 A A-and-B feed. One side at 30 A is about 10.8 kW nameplate. Apply the 80 percent continuous limit and each side holds about 8.6 kW. Now hold each side to its failover budget so either can carry the rack alone, and the usable continuous load lands near 8.6 kW for the pair, not the 21.6 kW the two 30 A inputs read on paper.

The figures below are illustrative, and the exact numbers depend on the voltage, the connector, the redundancy scheme, and the listing, so run them for the real install rather than copying the table. The shape is the point. The usable kilowatts are a fraction of the installed amperage once the continuous derate and the redundancy budget are taken out.

This is the calculation that should drive how many racks fit on a floor PDU and how many servers fit in a rack. Plan on the installed amperage and you oversubscribe. Plan on the usable number after both derates and you get a count you can actually fill without tripping anything.

How redundancy cuts usable capacity below installed

Redundancy buys uptime by holding spare capacity in reserve, and that reserve is capacity you cannot fill. Usable capacity is always less than installed capacity, and the gap is set by the redundancy scheme. This is the rule that surprises owners reading the megawatt number on the one-line: the building does not get to use all of it.

N is the bare capacity to carry the load with nothing to spare. N+1 adds one more unit than the load needs, so a failure or a maintenance window does not drop the load, and the usable load is N out of N+1 installed. 2N fully duplicates the system into two independent sides, each able to carry the whole load alone, which means each side runs at no more than half and half the installed capacity is held in reserve by design. The Uptime Institute Tier framework is where these levels get formalized when a Tier is claimed.

None of this is waste. It is the price of riding through a failure without an outage. The planning error is forgetting it: sizing the floor to the installed capacity instead of the usable capacity under the redundancy scheme, then oversubscribing the room until the first failure has nowhere to fail over to. Plan on the usable number. The reserve is not yours to fill.

Cooling capacity has to match power capacity

Cooling capacity has to match power capacity, because every watt a server draws comes back out as heat. Power in equals heat out, near enough that you size the cooling to the electrical load and the two move together. A hall with 2 MW of IT power needs roughly 2 MW of heat removal at the racks, and if the mechanical plant cannot remove it, the power capacity is stranded no matter how many breakers are open.

This is why cooling so often binds before power as density climbs. A circuit to a rack is cheap to oversize. Removing 40 kW of heat from one cabinet is not, and air alone struggles past roughly 20 kW per rack without aggressive containment. Push the density higher and the cooling, not the power, is what caps the rack.

The mechanical side is its own discipline, and the thermal envelope guide covers the ASHRAE inlet target the cooling has to hold while it removes that heat. For capacity planning the rule is simpler: track cooling as a capacity in its own right, in kilowatts, alongside power and space, and never commit power you cannot cool. High density forces containment and increasingly liquid cooling to keep the heat capacity matched to the power, because the air ran out of room first.

How many kW per rack is high density?

High density today means a rack pulling far more than the 10 to 20 kW a mainstream cabinet draws, and for AI and GPU compute that increasingly means 50 to 100 kW and beyond in a single rack. There is no fixed line, because the threshold moves every year, but a useful working split is that anything air can still cool sits below roughly 20 kW, and anything above it is high density that forces a different approach.

The dense rack reshapes the whole capacity plan. The power lands as three-phase at higher voltage and amperage, often 415 V three-phase, fed from overhead busway rather than a fixed whip so taps can be added as racks land. The rack PDU types guide covers the strip, the phase, and the busway feed at the cabinet. The heat goes to liquid, because air cannot carry it off the chips at that density. And the cooling capacity per rack, not the floor space, becomes the constraint that decides how many of these racks the room can hold.

Treat the kW figures as a snapshot. The constant is the direction: more power per rack, three-phase at higher voltage, busway feeds, and liquid carrying the heat the air no longer can.

Spreading the load versus packing it

There are two ways to place a given load on a floor, and the choice trades cooling difficulty against rack count. Spread it out and you run more racks at lower density, which is easy to cool with air and easy to feed, but it eats floor space and stretches the network and power runs. Pack it in and you run fewer racks at high density, which saves space and shortens the runs, but concentrates the heat and forces containment or liquid to remove it.

For years the default was to spread, because air cooling was cheap and floor was the thing that ran out. Density has flipped the calculation. Floor is no longer the binding capacity in most halls, and the GPU clusters that drive new builds want to be packed tight anyway, because the interconnect between accelerators is faster and cheaper over short distances. So the modern lean is toward packing, paid for with the cooling to match.

There is no universal answer, and the right move depends on which capacity is scarce in your room. If cooling is tight and floor is plentiful, spread. If floor and network reach are the constraints and you can cool it, pack. The capacity model is what tells you which case you are in before you commit the layout.

The capacity model and DCIM

A capacity model is the live record of how much power, cooling, space, and network port you have against how much is committed, kept current rack by rack so you can answer one question without walking the floor: where does the next server go? That model usually lives in a DCIM platform, data center infrastructure management, which ties the power feeds, the cooling, the rack space, and the network ports into one picture.

The value is that it makes the three capacities visible together. A good model shows that a given rack has breaker headroom but no cooling left, or that a floor PDU is full on power while its aisle still has cooling to give, so a placement decision is made on data instead of on which cabinet happens to have an empty slot. Without it, capacity is tribal knowledge in a few people's heads, and it goes wrong the day one of them is on vacation.

A model is only as good as the data feeding it, which is the catch. A DCIM populated from nameplate values and design assumptions reports confident, precise, wrong numbers. Feed it metered load from the rack PDUs and the branch monitors and it becomes the instrument the floor is run from. Garbage in is worse than no model, because it is trusted.

Measured data: metering and EPMS

You cannot plan capacity on numbers you do not measure. The instruments that produce the real load are the metered and intelligent rack PDUs at the cabinet, the branch-circuit monitors at the floor PDU, and an electrical power monitoring system, EPMS, watching the chain from the utility inlet through the UPS to the distribution. Together they read the actual draw per outlet, per rack, per phase, per circuit, and per feed, which is the data the capacity model runs on.

Metering is also what finds stranded capacity. A per-phase reading shows the floor PDU loaded heavily on two phases and idle on the third, which is capacity hiding in plain sight. A per-rack trend shows the cabinet the operators guessed full is running at half its budget. None of that is visible from nameplate math or a design spreadsheet.

The same meters feed the efficiency numbers. PUE, power usage effectiveness, is total facility power over IT power, defined by the Green Grid, and it is only as accurate as the metering behind it, which is why granular EPMS data is the basis for a real PUE rather than a marketing one. The rack PDU types guide covers the strip-level metering, and the thermal envelope guide covers tying the inlet sensors into the same view. Meter first, plan second.

Forecasting growth and holding headroom

Capacity planning is a forecast, not a snapshot, because the load grows after turnover and the density of each refresh climbs. A hall built for the racks of its first year will see denser gear at every hardware refresh, and a plan that does not leave headroom for that runs out early. The forecast is the difference between adding capacity on a schedule and scrambling when a breaker or a cooling plant hits its limit.

Forecast each capacity on its own curve, because they do not grow together. Power and cooling demand climb with density at refresh. Space can stay flat or even shrink as racks get denser, which is why the old habit of planning floor first reads backward now. Track the trend per capacity from the metered history, project it forward, and hold a headroom margin that buys the lead time to install more before you need it.

The expensive miss is planning to today's load with no headroom, filling the room, and then discovering the next refresh has nowhere to land. Adding power or cooling to a live hall is slow and disruptive, and sometimes it means the next building. Forecast the rising density, hold the headroom, and add capacity on a plan instead of in a panic.

Phase balance across the racks

Three-phase distribution only delivers its full rating when the load is spread evenly across the three phases. Pile the single-phase loads onto one phase and that phase trips or strands capacity while the other two coast, so the feed reads full on paper and half empty in reality. A common operational target is to hold the phases within about 10 percent of each other, with the equipment ratings and the design setting the real limit.

For capacity planning the point is that phase imbalance is stranded capacity wearing a different hat. The kilowatts are installed and paid for, and the imbalance makes part of them unreachable. The rack PDU types guide covers balancing at the strip, including strips that alternate the phase outlet by outlet to hold balance as a rack fills. Watch the per-phase metered load at the floor PDU and the rack, and rebalance before one phase pins while the others idle.

Design density versus the as-built operations model

The density a hall was designed for and the density it actually runs at are two different numbers, and the handoff between them is where capacity planning lives or dies. The design carries a planned watts-per-rack and a total load the power and cooling were sized to. Commissioning proves the installed capacity is really there, that the redundancy fails over, and that the cooling holds the inlet at full load. Then operations has to keep a capacity model against the as-built numbers, not the design assumptions.

The gap that bites is when operations plans on the design density while the floor fills with denser gear, or plans on nameplate while the meters say something else. The design said 8 kW a rack, the racks came in at 14, and the room is full at sixty percent of its planned rack count with nobody having updated the model. Now the next order has nowhere to go and the surprise lands at the worst time.

Carry the real numbers forward from commissioning into the operations model, and update them from the meters as the floor changes. The design is where the room started. The measured, as-built capacity is what you actually have to plan against, and the two drift apart the day the first rack lands.

AI and hyperscale: when power is the bottleneck

At hyperscale the capacity conversation has moved from megawatts to gigawatts, and power has become the binding constraint for the whole industry, not just the room. The largest AI builds are sized in hundreds of megawatts and reaching toward the gigawatt, and the limit is increasingly whether the utility and the grid can deliver the power at all, and on what schedule. Land and steel show up faster than substations and transmission.

For a single facility this changes what capacity planning even optimizes. When the grid connection is the scarce resource, every watt that gets stranded inside the building is a watt of a constrained, hard-won supply wasted, which raises the stakes on everything in this guide: measured load over nameplate, balanced phases, unstranded headroom, and usable capacity planned honestly under the redundancy. The bigger the build, the more a planning miss costs, because the power behind it was the hard part to get.

What to document

Without a written capacity plan there is nothing to hand the next planner and nothing to point to later. The record is what the next planner reads before committing the next rack, and what answers the question months later when the room fills faster or slower than expected and someone asks whether the numbers were ever right.

Capture the design and the measured density per rack and per row, the installed and the usable capacity for power, cooling, and space, the redundancy scheme and the failover budget it imposes, the per-phase balance, the metering source for each number, and the growth forecast and headroom margin. The point is that a reviewer can see, from the record alone, how full the room really is and which capacity binds first.

Common mistakes

• Planning capacity on the nameplate rating instead of the measured draw, which strands half the room.
• Letting capacity strand because a cooling limit, a PDU, or a breaker caps power you already paid for.
• Oversubscribing past the redundancy headroom, so the first failure has nowhere to fail over to.
• Running no DCIM or metered capacity model, so capacity is a guess in a few people's heads.
• Packing high-density racks without the cooling to match, so the heat caps the rack the power could feed.
• Leaving the three phases out of balance, so one phase pins while the other two coast.
• Sizing a rack or a floor PDU to the breaker instead of the 80 percent continuous limit.
• Planning on the design density while the floor fills with denser refresh gear.
• Forecasting no growth, filling the room, and finding the next refresh has nowhere to land.
• Sizing the floor to installed capacity instead of the usable capacity under the redundancy scheme.

Field checklist

Standards and references

No single body owns capacity planning, so the references come from a few places, each governing a different piece. The Uptime Institute Tier framework defines the redundancy levels, N, N+1, and 2N, that set how far usable capacity falls below installed, and it is the reference owners cite when a Tier is claimed. ASHRAE Technical Committee 9.9 governs the cooling side, the thermal guidelines and the inlet conditions the density has to live inside, covered in the thermal envelope guide. The Green Grid defines PUE, power usage effectiveness, the efficiency metric the metering feeds, with the broader ISO/IEC 30134 family of data center KPIs around it.

The electrical limits come from the NEC, NFPA 70, and the UL listings of the distribution gear, including the 80 percent continuous-load convention that sets the usable fraction of every breaker. The equipment nameplate is the manufacturer's worst-case figure, and the measured draw is the number to plan on, so treat the nameplate as a ceiling and the meter as the truth.

Hedge every kW and density figure in this guide to a snapshot. The numbers climb each year, and the right figure for your room is the one the design and the measured load give you, confirmed against the adopted code and the equipment listings before you commit it to a submittal. Two rules hold above the rest: plan on measured load, not nameplate, and plan on usable capacity, not installed.

Units, terms, and acronyms

Capacity planning carries its own vocabulary, and the same load reads differently across a one-line, a DCIM screen, and a utility bill.

Power and cooling are both stated in kilowatts, because power in equals heat out, and at scale in megawatts or gigawatts. Density is kilowatts per rack, sometimes per cabinet, per row, or per square foot of white space. Current is in amps, and the feed is rated in amps before the 80 percent continuous derate. Efficiency is PUE, a ratio with no unit. The terms below travel across the plan, the install, and the operations model.

Power density

Electrical load in a footprint, usually kilowatts per rack, also per row or square foot

Stranded capacity

Power, cooling, or space paid for but unusable because another limit caps it first

Nameplate rating

The manufacturer's worst-case maximum draw, well above the actual measured load

Design / derated load

A planned fraction of nameplate, commonly 50 to 75 percent, used to size systems

Usable capacity

Installed capacity minus the redundancy reserve and the continuous-load derate

N+1 / 2N

Redundancy schemes; N+1 adds one spare unit, 2N fully duplicates the system

DCIM

Data center infrastructure management, the platform holding the live capacity model

EPMS

Electrical power monitoring system, metering the chain from the utility inlet down

PUE

Power usage effectiveness, total facility power divided by IT power; lower is better

The three capacities

Power, cooling, and space; the site runs out of whichever binds first

Related tools

Calculators and readiness checks for this work

Compare your options

FAQ

People also ask

• What is a rack PDU?
• What is the ASHRAE recommended temperature for a data center?
• What is stranded capacity in a data center?
• What does DCIM stand for and what does it manage?
• How do you size a data center generator?