Built for Hyperscale: The System of Record for the AI Datacenter
The system of record for an AI datacenter has to describe the building, not only the network, and it has to take writes from pipelines and agents at the rate they produce them.
A GB200 NVL72 puts 120 kilowatts in a single rack, and by NVIDIA‘s math, cooling that with air would mean chilling the room below freezing or moving the air at near-gale speeds. Whether a rack can take that hardware comes down to the cooling the rack can deliver and the power path behind it, and a record that stops at the server cannot answer it.
Task-specific AI agents are arriving in enterprise applications fast. In an AI datacenter, automation was already the main writer before agents arrived. The pipelines that stand a site up also populate and update it, and the systems that read it never open a browser.
Neither requirement is enough on its own. A record that models the rack but cannot absorb writes at machine speed falls behind the build, and one that keeps pace but only knows the network still cannot say which racks will take the hardware.
Today TurboBulk, the NetBox Labs platform’s high-performance bulk data API, reaches GA on the SaaS edition, with the self-managed edition to follow soon. It joins a set of capabilities already on the platform, and it is the latest enhancement resulting from the AI Datacenter Acceleration Program announced last November. Together they add up to a record that describes the whole infrastructure, keeps pace with the build, and stays reviewable no matter what writes to it.
The record describes the infrastructure, not just the network
Operators can describe every server and switch they run and still not know which racks will take a liquid-cooled chassis, because power, cooling, and optical live in other tools. In NetBox 4.7, cooling capability and capacity sit on the rack itself, alongside the power model NetBox has carried for years, so determining which racks can take that chassis becomes a filter on the record rather than a meeting with facilities. Both ship in open source core, in every install and every edition. With Custom Objects, a no-code way to define object types the model has no table for, a VXLAN tunnel endpoint or a software license gets a first-class object without waiting for one to be added to NetBox core.
A device type arrives with NetBox Data Exchange (NDX) enrichment attached as its own object, thermal and end-of-life data from the curated catalog that you can read in the UI or pull through the API, so planning starts the day the type is added, not the day someone reads the vendor PDF. Asset Lifecycle extends the record into procurement. It turns the design built on those types into a bill of materials and follows each item through purchase order, shipment, and installation, so what gets ordered matches what the racks were planned to hold.
The community is already working on optical. netbox-wdm, a newly certified plugin, models WDM wavelengths on the fiber they run over. It is alpha today. Open source users can install it themselves, and NetBox Labs can enable it upon request in the SaaS edition.
At the scale these sites run, NetBox Visual Explorer, the platform’s interactive view of that same data, maps how a site actually connects, across the fabric and down to the rack. It is in public preview today.
Cooling data is yours to populate. NetBox Discovery covers the network, not the cooling systems behind it, so bulk import and the API are the way to bring that data in. We expect improvements here in the coming quarters.
The record keeps pace with the build
Populating a site by hand does not finish before the site changes. Pipelines that write thousands of objects at once time out at the proxy or collide with each other. The heaviest reads run in the same change windows as the writes.
With TurboBulk, tens of thousands of objects can be ingested in seconds. Once the objects are in, NetBox Discovery keeps the network side current from live state, and NetBox Assurance flags where the two have drifted, so the record does not decay between builds. Event Streams puts every change on the cloud event bus, and downstream systems stop polling the primary for it. Reporting and other heavy reads run against Replica Cache, now in public preview, instead of the primary database, out of the way of the writes landing in a change window.
The record stays reviewable no matter what writes to it
When the writers are pipelines and agents, changes arrive faster than any review built for humans, so governance has to be built into the path a change takes. On the NetBox Labs platform, that path is open to every writer. A change can land in a branch, which NetBox Branching isolates from the live record and shows as a diff before it merges. Once merged, it is an explicit change record in NetBox Changes for review, analogous to a pull request in GitHub. An agent enters that path through the NetBox Labs Platform MCP, a governed interface rather than a raw API token, and NetBox Agents proposes its changes as branches like anyone else. Both are in public preview.
Get started
If you are on NetBox 4.7, cooling capability is already on your racks. That layer of the model is open source, in every install, and the netbox-wdm plugin installs on any of them.
The scale layer above it is the commercial NetBox Labs platform, on the SaaS and self-managed editions. If you are building at the scale where that layer matters, talk to us.
