NetApp names Nebul as first neocloud on Novus and states Novus is generally available; no performance, scale or contract data disclosed

NetApp; Nebul (European AI-native cloud provider) · AI cloud infrastructure (neocloud / GPU-as-a-service); SLED applicability limited and by interpretation · Netherlands / European Union; no U.S. deployment stated

NetApp

Publisher: NetApp Newsroom
Original publication: 2026-11-10 (NetApp press release dated San Jose, November 10, 2026)
Source retrieved: 2026-11-11
Event date: 2026-11-10

Read original source

What happened

NetApp announced on 10 Nov that Nebul, a Netherlands-based AI-native cloud provider, is the first neocloud to adopt NetApp Novus, and states Novus is now generally available. NetApp repeats its design figure of up to 100 TB per second of aggregate throughput and says Novus scales performance, capacity and concurrency independently under one namespace. Because Novus is built on ONTAP, NetApp says ONTAP customers can extend existing data estates into sovereign cloud environments while keeping jurisdiction and access policies. A NetApp executive cites government, healthcare and biotech compliance and multi-tenancy needs. The companies say they are 'exploring opportunities'; no contract value, deployed capacity, GPU count, go-live date or measured results are given. Why now: first named Novus customer and first explicit general-availability statement, published after the last NetApp run; not in the archive.

Why it matters

Interpretation, limited applicability: this is a European sovereign-cloud deal, not a U.S. SLED deployment. The relevant signal for U.S. research universities and state agencies is that Novus has moved from launch to a named production adopter, and that NetApp is positioning ONTAP data-estate extension into third-party GPU clouds under existing access policies. Research-computing teams evaluating GPU-as-a-service or campus AI factories can ask whether a provider runs Novus, but should not treat this release as evidence of performance or public-sector fit in the U.S.

Evidence and measured results

Vendor press release only for the adoption itself; Nebul's own copy (dated Leiden, 10 Nov) repeats the same text. Independent commentary (Tech Thought Leaders, 5 Oct 2026, written by a SUSE product-marketing manager) says the 100 TB/s figure is a vendor claim no independent benchmark has reproduced; archived Futurum and ITdaily analyses make the same point. A DDN blog (21 Oct 2026) states Nebul already runs DDN Infinia under its inference stack for KV cache, and that Centric, whose software supports about 70% of Dutch municipalities, uses Nebul for sovereign inference, so Nebul is a multi-vendor storage environment and Novus' role there is unspecified. No benchmark, utilization figure or customer measurement for Novus at Nebul was found.

Limitations and uncertainty

Vendor-claim. 'Fastest storage on the planet' and 100 TB/s are NetApp design claims without disclosed test conditions. Release includes a forward-looking disclaimer. European sovereignty framing (EU jurisdiction, CLOUD Act concerns on Nebul's government page) does not map directly to U.S. state requirements such as CJIS or FedRAMP-equivalent state programs. Cross-stream note: DDN and NVIDIA appear only as context.

Put this evidence to work

Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-11; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.

Sales

Role takeaway

Customer problem: Research universities and large public data centers building or renting GPU capacity face data-path and namespace limits that leave GPUs underused, but lack independent evidence about new AI storage architectures.
Stakeholders: Research computing director
University or state CIO/CTO
Data governance / privacy officer
Procurement lead for cloud and GPU services
Discovery questions: Is GPU utilization measured, and is storage throughput a known bottleneck?
Do you rent GPU capacity from neoclouds, and which storage do they run?
Must AI training data stay under specific jurisdiction or contract controls?
Is existing research data on ONTAP that you would extend to a GPU provider?
Value hypothesis: For institutions with ONTAP-resident research data and large GPU fleets, Novus may offer a single-namespace data path worth evaluating, contingent on workload-specific testing.
Potential engagement: A bounded architecture briefing and requirements workshop on GPU data paths and namespace design for one research-computing or state data-center team.
Unsupported claims: The 100 TB/s figure as achievable throughput
'Fastest storage on the planet'
Any U.S. SLED adoption of Novus
That jurisdiction and access policies are automatically preserved in a provider cloud
GPU-utilization gains for any specific workload

Pre-sales engineering

Role takeaway

Fit: Potential fit only for large, multi-tenant GPU environments (research computing, shared state AI platforms) with a single-namespace requirement; not relevant for typical departmental file or VM workloads.
Architecture and integration: Metadata tier on qualified Supermicro servers plus ONTAP data nodes (AFF A90 in initial release per independent coverage), accessed via standard NFSv4.2/pNFS with GPUDirect Storage; extension of existing ONTAP estates to a provider is asserted but not specified.
Prerequisites: Measured baseline of GPU utilization and storage throughput
Client OS kernels supporting NFSv4.2/pNFS
Network fabric sized for target aggregate bandwidth
Defined data-residency and access-policy requirements
Constraints: No published independent benchmark
No U.S. or public-sector reference deployment stated
European sovereignty model does not map to U.S. state compliance regimes
Provider environments may be multi-vendor (Nebul also runs DDN)
Security: Tenant isolation and policy preservation are asserted, not documented; underlying ONTAP and BMC components inherit NetApp advisories and must be in the patch scope.
Proof of value: Run workload-representative read/write tests including small-file metadata and checkpoint writes
Test throughput under concurrent multi-tenant load
Verify access-policy and audit continuity when data is extended to the provider
Confirm patch cadence for ONTAP and controller firmware in the provider stack

Delivery

Role takeaway

Work: Track as a market signal; if a pilot follows, run a defined benchmark and governance-mapping exercise before any production commitment.
Dependencies: Customer GPU environment or provider access
NetApp and provider engineering support
Data-governance sign-off on residency
Ownership: Research computing or state data-center operations would own any pilot; data governance owns residency and access approval.
Skills and adoption: Requires pNFS/GPUDirect Storage and ONTAP skills plus performance-testing capacity that many SLED teams lack; plan partner support.
Governance checkpoints: Requirements and residency review before pilot
Benchmark plan approval
Security review of tenant isolation and patching
Go/no-go on measured results
Acceptance criteria: Pilot meets an agreed throughput and GPU-utilization target under concurrent load
Access policies verified unchanged after data extension
Documented patch path for all Novus components
Risks: Over-reliance on vendor design figures
Provider lock-in or unclear multi-vendor data paths
Compliance mismatch between EU sovereignty model and U.S. state rules
Immature product with few production references

Implementation considerations

Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.

Architecture and integration

What must connect, and where does the AI sit in the workflow?

Novus separates metadata (NetApp metadata software on qualified Supermicro servers, per independent coverage) from ONTAP data services (initial release on AFF A90 per independent coverage) behind standard NFSv4.2/pNFS clients. For SLED, the architecture matters mainly where an institution or its GPU-cloud provider needs one namespace across many GPU servers; extending an on-premises ONTAP estate to a provider would rely on ONTAP replication/mobility features not detailed in the release.

Governance

Who approves, reviews and stays accountable for outcomes?

NetApp's claim that data 'maintains its existing jurisdiction and access policies' when extended to a sovereign cloud is a design intent, not a verified control. Any public-sector use of a third-party GPU cloud would still need data-residency, contract and audit terms negotiated with the provider.

Security and privacy

What data, permissions and controls need testing?

Multi-tenant isolation is asserted but not described. Novus runs on ONTAP and AFF hardware, so ONTAP and BMC advisories (including NTAP-20261102-0001 in this edition) apply to the underlying stack.

Accessibility and workforce

Who is affected, and what skills or accommodations follow?

Highly specialised skills (parallel file systems, GPU data paths) would be needed; no accessibility content in sources.

Procurement

What should contracts, pricing and exit terms secure?

No pricing or contract terms disclosed. U.S. public buyers would procure through NetApp channels or via a GPU-cloud provider; neocloud sourcing raises residency and contract questions distinct from hyperscaler vehicles.

Operating model

Which teams own the service once it runs?

Shifts storage decisions toward GPU-cloud providers; SLED institutions renting GPUs should ask providers about storage architecture and patching rather than assume it.

Publication history

2026-11-10NetApp · Issue 122 resources

Read preserved resource versions (JSON)

Stable resource ID: netapp-novus-ga-first-neocloud-nebul-sovereign-ai-20261110