When an enterprise decides to build an artificial intelligence platform, the first instinct is often to pick the fastest storage on the market. Experience shows, however, that no single file system or block storage can cover every phase of the model lifecycle. An AI data pipeline is not a homogeneous workload; it is a succession of stages from massive raw data ingestion to production inference, including curation, distributed training, checkpoint management, artifact registry, and telemetry. Each stage imposes different requirements for performance, consistency, durability, and access patterns. Therefore, architects and platform teams must think in terms of storage contracts, not product names.
At Q2BSTUDIO, a software and technology development company, we have accompanied organizations in designing AI infrastructures that integrate multiple storage layers. Our approach combines custom artificial intelligence solutions with a solid architecture that avoids bottlenecks and unnecessary costs. In this article we explore where and when to use PowerScale (NFS), PowerFlex (block), vSAN, object storage, and local NVMe in a VMware Cloud Foundation 9.1 environment, offering a practical guide to classifying data before choosing the physical media.
Classify data as the first step
Before deciding which storage system to use, you must answer fundamental questions about each dataset: Can it be rebuilt if lost? Is it needed by a single node or multiple nodes concurrently? Is it immutable after approval or constantly rewritten? Are operations large and sequential or small and random? What are the recovery point objective (RPO) and recovery time objective (RTO)? These variables define the service contract that storage must satisfy. For example, a training dataset read in parallel by multiple workers requires a high-performance shared file system (ReadWriteMany), while a registry metadata database requires predictable latency and exclusive access (ReadWriteOnce). The most common mistake is treating all data as the same type and placing it on a single infrastructure.
PowerScale NFS: the shared data layer
Dell PowerScale, with its OneFS file system and NFS protocol, is the natural choice when multiple workers, pods, or teams need concurrent access to datasets, curated corpora, or distributed checkpoints. Its architecture scales in aggregate bandwidth and metadata operations, making it ideal for training workloads that read large sequential shards and for collaborative curation environments. In a VCF 9.1 cluster, PowerScale connects via a dedicated high-speed network. It is important to design separate namespaces per tenant or project, with access zones, quotas, and export policies. However, it should not be used for transactional databases requiring low block latency, nor for temporary data that should reside on local NVMe. Performance is measured in aggregate GiB/s and metadata operations per second, not random IOPS.
PowerFlex and vSAN: the persistent state layer
Dell PowerFlex provides shared block storage with predictable latency. It is the preferred option for platform services that need RWO volumes: registry databases (Harbor, MLflow), message queues, vector databases, or orchestration metadata. In VCF 9.1, PowerFlex can act as principal storage for the workload domain or as supplemental storage. vSAN, on its part, offers native integration with vSphere and policy-based management. Both solutions must be validated with p95/p99 latency tests during snapshot, resync, and maintenance operations. A frequent mistake is treating shared block as a multi-node file system without application-level coordination: an RWO volume can technically be mounted on several nodes, but most applications do not guarantee consistency in that scenario. PowerFlex and vSAN excel at storing service state, not shared datasets.
Object storage: durability and governance
For raw data, model artifacts, backups, and long-retention logs, object storage (S3-compatible) is the appropriate layer. It offers durability, immutability through retention policies (Object Lock), and automated lifecycle management. In an AI pipeline, original datasets should be preserved in objects, while working copies reside on PowerScale or NVMe. Approved model artifacts are stored in versioned, immutable buckets. RAG (retrieval-augmented generation) workloads benefit from native API access. However, it is crucial not to force POSIX semantics over objects via gateways: applications requiring atomic renames or random block access will perform poorly. Object storage is the ideal partner for data governance, provided retention and deletion policies are linked to legal regulations.
Local NVMe: disposable acceleration
Local NVMe on GPU or compute nodes is designed for data that can be easily rebuilt: input data caches, decompressed shards, temporary shuffle, kernel compilations, and hot model files for inference. The golden rule is that if the node is lost, the platform must be able to regenerate that content from a durable source without manual intervention. Therefore, it should not be used for data that lacks an authoritative copy elsewhere. Moreover, in virtualized Kubernetes environments, an emptyDir volume may be backed by the VM’s virtual disk rather than the host’s physical NVMe; the actual I/O path must be verified. Local NVMe reduces latency and avoids network saturation but introduces node affinity that complicates scaling and maintenance. It is an acceleration layer, not a persistence layer.
Integration in VCF 9.1: a reference pattern
VMware Cloud Foundation 9.1 provides the orchestration foundation to combine these storage types. The management domain can use vSAN or supported principal storage; the AI workload domain benefits from PowerFlex for stateful volumes and PowerScale for shared data. Object storage is connected externally, and local NVMe is managed through ephemeral volumes. The key is to define Kubernetes storage classes that reflect capability contracts (e.g., ai-rwx-throughput, ai-rwo-low-latency) instead of product names. This way, applications request a service without being coupled to a specific vendor. Additionally, it is essential to measure performance under combined load: a nightly checkpoint peak must not degrade registry database latency or RAG ingestion.
Q2BSTUDIO’s role in AI architecture
At Q2BSTUDIO we understand that infrastructure is only part of the success. That is why we offer services ranging from platform design to development of custom software that integrates with these storage systems. Our team helps classify data, define lifecycle policies, implement AI agents that optimize data movement, and deploy cybersecurity solutions that protect the most valuable assets. We also work with AWS and Azure cloud environments to extend the AI pipeline to the cloud when elasticity is required, and we apply Business Intelligence with Power BI to monitor infrastructure performance and cost. The right combination of storage and intelligent software makes the difference between an AI project that scales and one that drowns in its own data.
Conclusion
An AI factory is not built around a single storage system. It is designed by identifying the different pipeline stages and assigning each the service contract that best fits. PowerScale for shared data, PowerFlex and vSAN for persistent state, object storage for durability and governance, and local NVMe for disposable acceleration. Integration in VCF 9.1 allows these layers to coexist in an orchestrated manner, but success depends on prior data classification and continuous performance measurement. At Q2BSTUDIO we help organizations navigate this path, combining technology, business knowledge, and custom software development so that AI becomes a real value driver.
