The nineteen-inch rack has been the unit of the data center for so long that it is easy to forget it is a convention rather than a law. Nearly everything about how facilities are designed, sold and operated assumes it: how space is leased, how power is handed over, how a technician expects to find equipment mounted.
Open Compute hardware does not follow that convention, and the places where it departs are not cosmetic. They are the places where a facility and a customer normally divide responsibility.
The width is the least of it
The most visible difference is that the equipment bay is wider than the conventional standard. That alone has consequences, because the ecosystem built around nineteen inches does not transfer: shelves, rails, blanking panels and the general assumption that a device bought from anyone will fit anything.
But width is a procurement nuisance rather than a facility problem. The differences that actually determine whether a rack can be installed are electrical.
Power arrives differently
In a conventional deployment the facility provides power to the cabinet, usually terminating in a rack power distribution unit, and every device plugs into it with its own cord and its own internal power supply. Metering typically happens at that PDU. Protection, monitoring and the per-device connection all live in the same familiar object.
An Open Compute rack moves that function. Conversion happens in shared power shelves within the rack, and distribution to the equipment runs over a vertical busbar at the rear that devices engage with directly. There is no cord per server and frequently no rack PDU in the conventional sense at all.
This is a sensible design for a large operator. Fewer conversion stages means less loss, shared shelves mean redundancy can be pooled rather than duplicated in every chassis, and removing hundreds of individual cords removes hundreds of things to get wrong. Our overview of megawatt rack power delivery covers why high-density racks have moved in this direction generally.
It is also a change in where the facility's responsibility stops. The handover is no longer a set of outlets. It is a feed into a rack whose internal distribution the customer owns. Metering, protection coordination and what exactly is being billed all need to be stated rather than inherited from the usual arrangement.
Questions that decide whether it can be installed
Most of the friction is discovered late, when hardware is already on site. These are the items worth settling in advance.
- How power is delivered to the rack. In what form, at what voltage, through what protective device, and terminating where. This is the single most common blocker.
- Where metering happens. If there is no rack PDU, the facility's usual metering point may not exist. Agree what is measured and where before the first invoice rather than after it.
- Physical access and footprint. A wider, heavier rack has to reach its position. Door widths, turning room and lift capacity decide this, and they are fixed properties of the building.
- Weight. Dense racks concentrate a great deal of mass on a small footprint. This is a real constraint and one our guide to rack weight and floor loading covers properly.
- Cooling at the density it will actually run. Not the density of the contract, the density of the workload.
- Who may work on it. If facility technicians are unfamiliar with the busbar arrangement, remote hands may be limited to tasks that do not involve the power path.
The cooling assumption travels with the hardware
Hardware designed for a particular kind of hall tends to assume that hall's cooling, and this is where a specification sheet can mislead.
A rack may be perfectly installable, correctly powered and mechanically fine, and still not be able to run its equipment at full output in a room that cannot remove the heat quickly enough. The failure mode is not dramatic. The equipment manages itself down and keeps working, and the customer gets less than they paid for without anything alarming.
The useful question for a facility is not the contracted density but the sustained one: what can this position actually dissipate, continuously, with neighbors also running. Our note on GPU rack and stack deployment goes through the installation side of that in more detail.
Why this is arriving in ordinary deployments
It would be reasonable to assume this only concerns operators running their own halls at enormous scale. That was true for a while and is becoming less so.
The designs developed inside large operators have propagated outward, partly because the vendors building accelerator systems for everyone else have adopted the same conventions. An organization buying a handful of systems for a specific workload can find that the hardware arrives with hyperscale assumptions built in, without ever having made a decision about rack standards.
That is the practical reason to understand this before purchase. The constraint is not really about Open Compute as a project. It is that any hardware designed around a specific facility model carries that model with it, and the place to discover the mismatch is at the specification stage rather than on a loading dock.
What to ask a provider
Two questions separate a facility that can take this hardware from one that will discover problems during installation.
The first is simply whether they have done it before, and what the arrangement was. A provider who has fed a busbar rack can describe how, in specifics. One who has not may still be able to, but the engineering is then happening for the first time on your deployment.
The second is where they draw the responsibility boundary when the rack contains its own distribution. A clear answer indicates they have thought about it. An answer that assumes a rack PDU indicates they have not yet.
If you are specifying hardware that does not follow the conventional rack model and want to know how it would be fed and cooled before you commit to it, get in touch. The mismatch is cheap to find now and expensive to find later.
Frequently Asked Questions
What makes an Open Compute rack different?
Three things, mainly. The equipment bay is wider than the conventional nineteen-inch standard, so ordinary rack-mount hardware and the accessories built around it do not transfer. Power is delivered to a vertical busbar at the rear that servers connect to directly, rather than through the familiar rack power distribution unit and a cord per device. And conversion from the room's supply happens in shared power shelves inside the rack instead of in a power supply inside every server.
Can a conventional colocation facility host one?
Often yes, but it is a question to ask rather than assume. The facility has to be able to deliver power to the rack in the form the rack expects, support its weight and footprint, and cool it at whatever density it actually runs. Any of those can be the blocker, and which one it is varies by site.
Why does the power delivery matter so much?
Because the conventional model assumes the facility hands over receptacles and the customer plugs in. A busbar-fed rack changes where the boundary sits: the facility is feeding a bus rather than a set of outlets, and the metering, protection and connection arrangements that normally live in a rack PDU have moved. That is a design conversation, not a patch cable.
Is this only relevant to hyperscale operators?
No, and that is the change. Form factors developed inside large operators now appear in hardware that enterprises buy, particularly accelerator systems. An organization with no intention of running a hyperscale estate can still end up with equipment that carries those assumptions, which is why it is worth understanding before the purchase rather than after.
A Real Energisation Date, Not a Brochure
Rax operates where transmission investment has run ahead of load, and we are direct about staged capacity and real dates. Talk to our team about sizing a deployment against a timeline.
Contact Rax Data & Energy