Infrastructure discussions usually offer two options: keep it in our data centre, or move it to public cloud. Colocation sits between them and gets left out, which is odd given how many of the problems in that discussion are facilities problems.
What it actually solves
You own the hardware and operate the platform. Somebody else owns the building, the power, the cooling, the physical security and the network connectivity.
That division is precisely aligned with the problem most enterprises have with accelerated infrastructure. The difficulty with dense compute is not the servers; it is that the data hall was designed for 6 kW per rack and cannot be upgraded without an electrical project measured in quarters.
A colocation facility built for current densities solves that with a contract instead of a construction project.
Where it wins
Power and cooling density. Purpose-built facilities offer per-rack power that most enterprise rooms cannot, and increasingly liquid cooling support. Buying this rather than building it removes the longest lead time in an AI infrastructure project.
Time. Space can be available in weeks. Upgrading your own facility is quarters at best.
Connectivity. Carrier-neutral facilities give you choice and usually direct connections to cloud providers, which matters if your architecture is genuinely hybrid.
Steady-state economics. For infrastructure running at high utilisation continuously, owning the hardware in someone else’s building is often the cheapest of the three options over a five-year view. You avoid consumption pricing on a workload with no idle capacity to reclaim, and you avoid capital spend on a building.
Sovereignty with flexibility. For organisations with data residency constraints, a local facility satisfies them while giving you a modern building.
Where it does not
Physical access. Your hands are no longer on the hardware. Remote hands services exist and cost money and introduce latency into every physical task. Teams used to walking into the data hall find this a real adjustment.
Term commitment. Contracts are multi-year with growth assumptions built in. Less flexible than cloud, more flexible than a building.
Variable workloads. If your utilisation genuinely varies, you are back to owning peak capacity, and the cloud argument reasserts itself.
Distance. If the nearest suitable facility is far from your other systems, latency coupling becomes a design constraint.
The comparison that should be run
Three columns, same assumptions, five years: own data centre, colocation, public cloud. Include in all three the staff cost, the refresh cycle where applicable, the network between locations, and the cost of the facilities work each option implies.
The frequent result, in my experience of watching these get built: colocation wins for steady-state and accelerated infrastructure, cloud wins for variable and new development, and the existing data centre keeps what is already there and working until its natural refresh.
That is a three-way split, which is less satisfying than a single answer and usually more correct.
Why it gets skipped
Because it does not have a marketing department pushing it into board conversations, and because it is neither the exciting option nor the incumbent one. It is a facilities decision wearing infrastructure clothes, and facilities decisions do not generate slide decks.
Put it in the comparison. For anything involving dense racks, it frequently wins on the one axis that is hardest to fix: how quickly you can actually have it.