Where AI Factories Hit their First Ceiling

• • Data gravity has a power bill.
  • Storage-embedded architectures consume facilities envelope at a structurally different rate than federated ones.
  • The three forms of data — data, metadata, vectors — have very different power profiles. An architecture that treats them as one substance overspends on the heavy one.
  • External forces (regulation, sovereignty, sustainability targets, grid availability) make the power envelope a hard constraint, not a soft one.
  • Three RFP questions expose the “building math.”

If you’re planning an AI “factory,” your biggest long-term constraint probably isn’t budget or GPUs. It’s how many kilowatts, rack units and backend switches your building can actually support and how much of that envelope your storage architecture silently consumes as you scale.

This post isn’t a field report. It’s the consequence of the laws laid out earlier in the series — data gravity, the three forms of data and the external forces that distort every real enterprise estate — translated into the line items facilities teams actually pay.

Why facilities is where the architecture gets graded

Most storage evaluations grade vendors on performance, capacity, features and price. Power and rack density are usually a footnote. In the era when a storage tier was a few racks of spinning disk, that was defensible. In the era of AI factories, it isn’t.

Storage is no longer a footnote in the facilities budget. For large NVIDIA-certified environments, it’s one of the three things the facilities team cares most about — alongside the GPUs themselves and the networking that connects them. And the architectural choice underneath it determines whether the building is a partner or a ceiling.

That ceiling arrives earlier than most teams expect. The building hits a single-digit percentage of its total power envelope. The next expansion doesn’t fit: not in megawatts, not in rack units and, in the detail that really stings, not in backend network switches, which have quietly become one of the biggest contributors to both. At that point the question that wasn’t in the original RFP becomes the only question that matters: how much of this power budget is being spent on the storage layer we chose?

The structural reason: storage-embedded architectures fight data gravity in watts

An AI factory has three power consumers that scale together: GPUs, networking and storage.

• • GPUs are a relatively fixed cost per FLOP. A vendor’s choice of accelerator matters less to the power envelope than how many of them the workload requires.
  • Networking and storage are highly architecture-dependent. Two platforms delivering the same throughput can draw dramatically different power based on how they’re designed.

Storage-embedded AI stacks tend to require more backend network switches because of how their disaggregated architectures fan out across the fabric.³ More backend switches means more rack units consumed, more cabling, more cooling, more power drawn, before a single GPU has turned on.

That’s the structural translation of the data-gravity argument from my first post. When the architecture is built on the premise that data has to be pulled into a central namespace before AI can run on it, the network and storage layers required to make that pull happen at scale have to grow with the data, and the growth shows up as switches, racks and kilowatts. None of that shows up on a storage spec sheet. All of it shows up on a facilities bill.

The three forms of data have very different power profiles

The three forms of data introduced in the first post aren’t just an architectural framing. They’re also a power framing.

• • Data — the heavy form. Files, records, images, video, telemetry, regulated tables. Power-expensive to host, more power-expensive to move, most power-expensive to duplicate. An architecture that requires this form to relocate before AI can use it will pay for that relocation in the facilities budget, every day, forever.
  • Metadata — lightweight. Negligible storage and compute footprint. An architecture that propagates metadata across the estate adds essentially no power load while delivering most of the visibility AI needs.
  • Vectors — moderate, but locality-sensitive. Vectors need to live near the GPUs that consume them. The right power question for vectors isn’t “how much,” it’s “how close.” KV cache offload (covered in the third post) is the canonical example.

A federated architecture that treats these three forms distinctly spends power on the workload, not on the relocation. A storage-embedded architecture that treats them as one substance defaults to the most expensive answer for all three.

The external forces make the ceiling permanent

The reason this matters more in 2026 than it did in 2022 is that the external forces acting on enterprise estates — the same forces named in my first and second posts — are tightening, not loosening:

• • Grid availability and lead time. New power to a data center is now measured in years in many regions. Architectures that overspend on facilities envelope can’t simply be “expanded out of.”
  • Sustainability and reporting requirements. Scope 2 and Scope 3 reporting put kilowatts on the same page as the AI strategy. In some instances, power use is now a required disclosure, not a footnote.
  • Sovereign and regional constraints. Data residency rules force capacity into specific regions where power and floorspace are scarcer and more expensive. The architecture that needs more of both pays more in exactly the regions where it’s hardest to get.
  • Colo and lease economics. When the building runs out, the alternatives — colo, lease, defer — all impose latency, operational or schedule penalties that compound the original architectural choice.

These forces don’t go away. They are the operating environment.

What the published numbers actually say

In October, Dell presented head-to-head comparisons to media and analysts that put numbers on the architectural difference. The specific claim, delivered by Dell’s SVP of ISG Marketing, Varun Chhabra: against published competitor reference designs running the same NVIDIA infrastructure, PowerScale used 72% less power, 80% less rack space and 8x fewer backend switches to deliver equivalent benchmark performance. The comparison against VAST specifically landed at 41% less power and roughly 2x less rack space for comparable performance.^¹

Those are big numbers. They deserve a careful read.

VAST has publicly pushed back, calling the comparisons “marketing math” and arguing that they rely on “selective, lab-grade configurations” and outdated reference designs.^¹ That’s a fair challenge. Any vendor-published comparison deserves scrutiny, ours included. So here’s what the briefing actually said, and what it didn’t:

• • The comparison was against published NVIDIA reference designs for equivalent benchmark workloads, not a head-to-head in a live customer environment and it does not attempt to capture every possible deployment topology.
  • The PowerScale F710 — the platform in the comparison — is NVIDIA Cloud Partner-certified and certified for NVIDIA DGX SuperPOD, in a 1U form factor, at 887 watts peak.^²
  • The rack, power and switch counts are driven primarily by the backend network architecture required to support equivalent performance. Fewer backend switches are the biggest contributor, and that compounds into less rack space, less cabling, less cooling overhead and less power.^²

VAST’s counter — that counting switches and rack units “doesn’t reflect how customers actually deploy AI infrastructure” — is the argument worth engaging with honestly. It’s true that live deployments don’t always follow reference designs. It’s also true that the facilities team doesn’t care. When a building runs out of power, it runs out of power against the deployment you actually have, not against the one the vendor slide deck assumed. Reference designs are the baseline because they’re the only apples-to-apples comparison available in public. If competitors want to publish their own full-methodology equivalents, the industry would be better for it. That offer stands.

One number worth naming directly: some VAST materials cite roughly 77% lower power and 73% less rack space from NVIDIA BlueField DPU offload, but those figures are improvements over VAST’s own pre-DPU baseline, not a head-to-head against an NVIDIA reference design that another vendor could reproduce. It’s a different question than the one on the table here.⁵

The federated answer, one more time

I’m going to repeat a point made in the previous posts, because the power story is where it lands most concretely.

The Dell AI Data Platform pairs PowerScale and ObjectScale with a federated control plane that operates on data where it lives.⁴ That design decision isn’t just about avoiding sync jobs or feeding GPUs more efficiently. It’s also about the facilities envelope, because a federated architecture doesn’t need to push every workload through a centrally hosted namespace, which means fewer backend switches, less duplicated fast-tier storage and a tighter power budget as the estate grows.

Translated into the three-forms framing: the heavy data stays in its existing facilities footprint, where its power cost is already paid for and accounted against the workloads that generated it. The metadata propagates across the estate at negligible cost. The vectors are placed where the GPUs need them, not duplicated across a centralized namespace. Each form pays only the power its actual job requires.

That’s the architectural difference, expressed in megawatts.^³

That’s also why enterprise AI buyers are no longer asking their partners for a spec sheet. They’re asking for a defensible answer about power, density and the long-term economics of the building they’re trying to fit AI into. The vendors — and the partners — who can walk that floor honestly are the ones winning this part of the conversation.

Three questions to ask before you sign

These are the ones your facilities team will thank you for.

1. 1. Publish rack U, kilowatts and backend switch count for your 16,000-GPU and 40,000-GPU reference designs, with sources. Vendors that will show the full configuration are telling you something. Vendors that won’t are telling you something too.
   2. At my target scale, what percentage of my total power envelope will your storage and backend network consume? A storage vendor who can’t answer that question isn’t ready for an AI factory conversation.
   3. If my facilities envelope tightens by 20% in three years, what does my expansion path look like on your architecture? This is a resilience question, not a gotcha. The honest answer will tell you how much optionality you’re really buying.

The shorter version: don’t discover halfway through the build that you were also buying a building.

What’s next

Post 5 leaves the facilities floor and goes back into the data layer: specifically, to what happens when engineers try to run standard Databricks and Snowflake workloads against an “AI database” and discover the database isn’t actually behaving like one. That’s where the three forms of data stop being a framing and start being an interoperability problem.

¹Johnson, O’Ryan, “Dell Targets Rivals Pure Storage And Vast Data As AI Race Heats Up,” CRN, November 2025. Covers Dell’s October 17, 2025 media and analyst briefing, including Varun Chhabra’s comparisons and competitor rebuttals. Power, rack, and switch comparisons based on Dell analysis of published NVIDIA reference designs.

²Noy, David, “Do More with Less: PowerScale’s Efficiency Advantage in NVIDIA Benchmarks,” Dell Technologies Blog, September 2025.

³Prowess Consulting, commissioned by Dell, “Architectural and Operational Comparison: Dell AI Data Platform vs. VAST AI OS,” April 2026.

⁴Dell Technologies, “Dell AI Data Platform with NVIDIA Supercharges Enterprise AI with Breakthrough Data Orchestration and Storage Innovations,” PR Newswire, March 2026.

⁵NVIDIA, “Spotlight: NVIDIA BlueField DPUs Power the VAST Data Platform for AI Workload Optimization,” August 2024.