NetApp unveiled Novus on 29 September 2026 as an AI storage architecture for very large GPU clouds, with a projected path to more than 100 terabytes per second of aggregate read throughput. The important distinction is that the headline number is a model of how the system could scale; NetApp has not published a measured 100 TB/s result from a production installation. For operators, the immediate news is a new way to separate file-location work from the movement of file contents while keeping one shared namespace.

Key takeaways

  • NetApp says Novus is orderable and initially combines Data Director software on qualified Supermicro servers with ONTAP services on AFF A90 storage systems.
  • The proposed 100 TB/s scale is a projection based on observed scaling tests, according to NetApp’s announcement and the independent analyst it quotes. It is not a public, end-to-end production benchmark.
  • The architecture uses standard parallel NFS access, a single namespace, and separately scalable metadata and data layers; buyers still need workload-specific proof for concurrency, latency, costs and resilience.

The launch took place during NetApp INSIGHT 2026 in Las Vegas, which ran from 29 September to 1 October. NetApp’s architectural explanation describes Novus as a response to an operational problem: expensive accelerators wait when storage cannot locate files, deliver training data, or write checkpoints fast enough. Separate accounts by Techzine, Hardware Upgrade and Mobile Time confirm the new product and its principal design. Hardware Upgrade explicitly distinguishes the projected headline from a measured deployment.

That distinction should frame any procurement discussion. AI storage is not purchased for an abstract top speed; it must support a specific mix of small-file reads, streaming reads, checkpoint writes and simultaneous tenants. A system might scale neatly on a sequential-read test while failing to improve a pipeline dominated by metadata requests or uneven data placement. Novus is a notable architecture announcement, but the most useful question is whether its promised separation improves the workload a customer actually runs.

Why AI storage becomes a bottleneck before GPUs run out

Large AI installations are often described by their processor count. Their economics, however, depend on how often those processors can do useful work. A model-training cluster may need to open many files, feed batches to accelerators, read feature data and write enormous checkpoints. A cloud operator may run several customers’ jobs concurrently, each with different traffic patterns. Storage has to satisfy those demands without creating a new administrative boundary each time another array is added.

NetApp offers a simple sizing illustration, not a universal GPU requirement: if each of 50,000 GPUs needs 2 GB/s, total demand reaches 100,000 GB/s, or roughly 100 TB/s using decimal units. Real demand depends on caching, model design, dataset format, network topology and the phase of a job. The calculation explains why a large AI cloud might care about aggregate bandwidth; it does not establish that every GPU constantly pulls that much data or that Novus has already supplied it in the field.

Illustrative bandwidth arithmetic for a large GPU clusterNetApp’s example multiplies 50,000 GPUs by 2 gigabytes per second each to arrive at 100 terabytes per second of aggregate demand. This is an illustrative calculation, not measured Novus performance.NetApp’s illustrative workload arithmetic50,000GPUs×2 GB/sper GPU assumption=100 TB/sillustrative aggregateSource: NetApp’s 29 September explanation. Arithmetic only; not a demonstrated deployment result.

Today, many installations address scale by adding systems and dividing datasets among them. That can improve raw capacity or throughput but leave users managing multiple file locations, policies and failure domains. The operating burden matters especially to a GPU cloud, where tenants may expect a consistent path to their data as clusters expand. AI storage can save time only if the operator also reduces the effort of moving datasets and maintaining those paths.

NetApp says Novus seeks to avoid that fragmentation by presenting one logical file system across many data nodes. Techzine’s account, based on discussions with NetApp executives, adds that the company sees continued ONTAP integration as a way to avoid another isolated data silo. That is a vendor rationale, not proof that migration, operations or troubleshooting will be seamless in every environment. Customers should ask how an existing ONTAP estate maps into the new namespace and which tools remain compatible.

AI storage design: metadata and data take different paths

A file system must answer two different questions. First, it has to identify a file, its permissions and where its data lives. That is metadata work. Second, it must actually transfer the file’s contents. That is data-path work. A single system may handle both, but the two types of traffic respond differently to scale: countless small lookups reward fast, concurrent coordination, while large reads and writes reward sustained bandwidth.

In NetApp’s description, Novus Data Director becomes an independently scalable metadata layer. Once a supported client obtains a layout, it can communicate with the storage holding the data. ONTAP-based AFF A90 systems supply the initial data layer. The architecture uses parallel NFS, or pNFS, a standards-based extension of the Network File System protocol. Its appeal is that supported Linux environments can use a standard access path rather than installing a vendor-specific client on every GPU node. The exact performance still depends on implementation and network configuration.

How the proposed Novus data path separates file location and contentA supported GPU client requests file layout from Novus Data Director metadata software, then reads or writes file contents directly through ONTAP AFF A90 data systems inside one namespace.One namespace, two independently scalable jobsGPU clientstandard pNFS accessData Directormetadata and layoutAFF A90 + ONTAPfile contents1. Locate the file2. Move data on the data pathDiagram based on NetApp’s architecture description; simplified and not a benchmark.

There is a meaningful technical nuance: separating the metadata plane does not make metadata disappear. It moves the bottleneck and allows operators to add resources to that layer independently. Buyers should still test namespace operations under realistic concurrency, especially when files are small or directories are deeply nested. They should also measure what happens during failure and recovery, when metadata availability is as important as peak read speed.

Hardware Upgrade reports that the first product configuration uses qualified Supermicro servers for the metadata software and AFF A90 arrays for ONTAP data services. It also reports a software-defined version is planned, with no announced delivery date. Therefore a buyer should assess the shipping configuration, not assume future hardware flexibility has already arrived. NetApp says the initial architecture can be ordered now. Being orderable is distinct from being installed at the advertised maximum scale.

The 100 TB/s number is a projection, not a field benchmark

NetApp’s announcement quotes an Omdia analyst saying observed tests showed near-linear gains as more ONTAP clusters were added to the same namespace. The analyst then describes a model projecting 100 TB/s of sequential-read throughput with very large capacity. Hardware Upgrade independently makes the crucial distinction: the 100 TB/s figure is projected from testing, not a measurement of a real installation operating at that speed. NetApp’s own release likewise calls the figure a projection based on observed testing.

This does not mean the architecture cannot reach the target. It means the evidence currently available to readers cannot prove that it already has. A reported scaling slope can be useful, but extrapolation depends on the absence of new limits at larger size. Network fabric, data distribution, recovery traffic, control-plane coordination and application access patterns can all change the result. Sequential reads are also only one type of workload. Most buyers will care about a combination of throughput, tail latency and cost per useful GPU hour.

The gap between a design target and a measured deployment should be visible in every retelling of this news. NetApp calls Novus the fastest storage on the planet, a comparative marketing claim in its announcement. It has not supplied a common independent test comparing Novus at its proposed maximum with all other AI storage systems. Lapaas Voice is therefore reporting the launch and the stated projection, not endorsing a speed ranking.

What is available today, and what remains to be demonstrated
Claim or feature Evidence now Buyer question
Novus is orderable NetApp’s 29 September announcement Which exact configurations and regions can be delivered?
Data Director plus AFF A90 NetApp architecture description; Hardware Upgrade and Techzine reporting What is the upgrade and failure-recovery procedure?
100 TB/s aggregate sequential reads NetApp/Omdia model from observed scaling tests Where is a reproducible full-scale workload result?
Standard pNFS client access NetApp design documentation and independent launch coverage Which Linux versions, network choices and tools are supported?

How this launch differs from the PEAK:AIO deal

NetApp had announced its intention to acquire PEAK:AIO on 25 September, identifying metadata architecture and parallel file systems as strategic capabilities. Novus is a separate product launch dated 29 September. The deal may explain why NetApp is investing in this part of the stack, but the company has not said that completion of the acquisition is a prerequisite for the initial Novus configuration. Treating the two announcements as one completed transaction would blur their distinct status.

The new system is also aimed at a different decision from the one many ordinary enterprises face. NetApp positions Novus for neocloud operators, hyperscalers and GPU-as-a-Service providers managing enormous shared installations. A company experimenting with a small internal model may need data governance, retrieval quality or affordable compute before it needs an architecture modeled for 100 TB/s. Readers following the economics of power and capacity can compare the infrastructure question with Lapaas Voice’s coverage of data-centre power capacity.

India’s relevance is indirect but real. Indian businesses that purchase GPU cloud services will experience the outcome as job completion time, data-transfer charges, availability and the ability to keep sensitive datasets in acceptable locations. Indian infrastructure builders could eventually evaluate this category when they operate clusters large enough to make a shared namespace and independent scaling materially useful. NetApp has not announced India pricing, a local Novus deployment or a specific Indian buyer in the 29 September material; those are open questions rather than launch facts.

What AI cloud buyers should test before signing

The first test is workload shape. An operator should replay its mixture of training-data reads, checkpoint writes, small-file opens and concurrent tenants. A sequential-read headline will not answer whether one tenant’s checkpoint stalls another tenant’s inference pipeline. Request not only average throughput but tail latency, job-level completion times and GPU idle time for the same application before and after any migration. NetApp’s own point is that useful accelerator time determines economics; a procurement trial should measure that outcome directly.

The second test is scaling method. Ask what additional components must be bought to increase metadata operations, network bandwidth or stored capacity separately. A system can scale on paper yet demand costly overprovisioning in practice. Confirm the number of AFF A90 systems, Data Director nodes, network ports and licenses needed at each planned step. Also ask for power, rack and operations estimates. None of these can be calculated reliably from the 100 TB/s aspiration alone.

The third test is resilience. A single namespace simplifies user experience, but it also makes service behavior during metadata loss, network partition or rolling upgrade extremely important. The vendor should demonstrate failover, consistency, restore and tenant isolation under load. Standard pNFS access may ease client management, but it does not remove server-side operational risk. Buyers with regulated workloads should assess how ONTAP policies, access controls and audit trails behave across the Novus configuration.

Finally, operators should check the boundary of the first release. The currently described combination uses Supermicro infrastructure for metadata and NetApp AFF A90 for storage. Future software-defined deployment is a roadmap item, according to Hardware Upgrade, not a dated product. Procurement documents should name the hardware, software version, supported clients and acceptance benchmarks actually available now. That makes the vendor’s architectural promise testable without dismissing it or accepting it on faith.

What is NetApp Novus?

NetApp Novus is an AI storage architecture announced on 29 September 2026 for large GPU clouds. It separates file metadata management from data transfer, keeps a single file namespace and initially combines Data Director software with ONTAP-based AFF A90 storage. NetApp projects the architecture can scale beyond 100 TB/s of aggregate sequential-read throughput; no public production measurement at that full scale has been presented.

Frequently asked questions

Has NetApp demonstrated 100 TB/s on a live Novus installation?

No public, end-to-end production result at 100 TB/s appears in the launch materials reviewed here. NetApp quotes an Omdia analyst whose model extrapolates from observed scaling tests. Hardware Upgrade also describes the figure as a projection.

Is Novus available to buy?

NetApp says the initial configuration is orderable. That configuration pairs Data Director metadata software on qualified Supermicro infrastructure with ONTAP data services on AFF A90 systems. The timing of any broader software-defined option is not specified.

Why does one namespace matter for AI storage?

A single namespace presents files through one logical structure as storage grows, reducing the need for users or applications to choose between separate locations. The operational benefit still depends on migration, access control and performance under the customer’s actual workload.

Does standard pNFS guarantee faster model training?

No. Standard pNFS can reduce dependence on a proprietary client and allow supported systems to access file layouts, but training speed also depends on data formats, caching, networking, software and the model itself. Buyers need job-level benchmarks to determine the gain.

Source note: Primary material is NetApp’s 29 September architecture blog and company release distributed by Business Wire. Independent reporting: Techzine, Hardware Upgrade, and Mobile Time.

Get the day’s top stories in your inbox

One concise email. No spam, unsubscribe anytime.