When Everpure introduced Data Primacy at //Accelerate in June, the idea was clear but largely conceptual: organizations should build their architecture around their data rather than around the applications that happen to hold it. Now the company is putting the first building blocks of that vision into customers’ hands, starting with Data Intelligence File Edition, which maps a data estate using metadata such as location, size, and access patterns without reading the contents of every file.
In this Q&A with VMblog, Ashish Gupta, General Manager of Everpure’s Data Management BU, explains how those capabilities fit into an end-to-end journey that runs from discovering and contextualizing data to preparing it with Everpure Data Stream, then supporting training and inference with FlashBlade and the Pure Key Value Accelerator (PureKVA). He also describes a new Intelligent Token Optimization reference architecture built on open weight models, designed to give organizations more control over where inference runs and how many tokens they consume.
Gupta also addresses the practical questions facing enterprises today: how to move forward without ripping out decades of application-centric infrastructure, why the enterprise data environment, not the model, is often what stalls AI in the pilot phase, and how better visibility and DeepReduce can curb hardware sprawl. Looking ahead, he makes the case that storage must evolve from simply holding data to managing it, preserving the context, governance, and ownership that AI agents will need to work with data in place.
++
VMblog: Everpure introduced Data Primacy at //Accelerate in June. How does this announcement turn that vision into something customers can actually deploy?
Ashish Gupta: At //Accelerate in June, we introduced Data Primacy, a shift in how organizations should think about their data, putting it first rather than the application that it lives in. Now, we’re putting some of the building blocks behind that vision into customers’ hands.
It starts with understanding what data you actually have. Our new Data Intelligence File Edition gives customers a way to map their data estate using metadata such as location, size, and access patterns, without having to read the contents of every file. From there, they can identify what is relevant, what is sensitive, what is at risk, and what may no longer need to be there.
Then you can start doing something with that intelligence–preparing the right data for AI, accelerate inference while making inferences more accurate, improve efficiency, and increasingly automate actions across the infrastructure. This isn’t just a vision of what data-centric architecture could look like, we are delivering this to our customers already.
VMblog: Given that Data Primacy shifts the core driver of enterprise architecture from applications to data, how does Everpure help organizations overcome the friction of legacy application-centric setups?
Gupta: The reality is that most enterprises aren’t starting from scratch. They have decades of applications, storage systems, clouds, and data environments that were built around the needs of individual applications. Seminal architectural and business process shifts like this take time, and it will be the same for these application wall gardens to be broken down and for the data and context that was in these applications to be liberated so that applications, agents, teams, and APIs will be able to work with this one source of truth. The answer isn’t to rip all of that out.
The first step is getting visibility across that environment. Data Intelligence is designed to work across heterogeneous infrastructure, including third-party storage, cloud environments, and mainframes. That gives organizations a common understanding of where their data is and what it represents, even when the underlying infrastructure is different.
Then, when customers are using Everpure infrastructure, we can bring in additional intelligence from Purity, Fusion, and Pure1, such as access and workload information. That creates a richer picture of the data and the infrastructure supporting it.
That’s really the transition we’re talking about. You don’t have to eliminate the application-centric world overnight. You can start building a layer of intelligence around the data and make it more coherent, less redundant, more contextually rich, and relevant on a scalable infrastructure.
VMblog: How do these new updates help businesses control and predict the often unpredictable costs of running AI inference?
Gupta: AI workloads can get expensive very quickly, and the cost starts well before you actually run the model. This is because you’re paying for infrastructure and data movement, in addition to paying for expensive compute, that are sometimes overprovisioned and underutilized, to process large amounts of data that aren’t relevant to the AI use case. This ends up costing more tokens than needed.
Because successful AI depends on core use cases, the full AI data lifecycle starts with discovering and contextualizing data, then preparing it, training models, and ultimately running inference.
It’s important to know what data you actually have and what is relevant. Data Intelligence helps organizations discover and classify data across their environments. It then adds the context needed to understand how that data can be used. The goal is to make your data AI-ready, identify the data that matters and make it usable.
From there, Everpure Data Stream helps prepare that data for AI by handling things like ingestion, vectorization, indexing, and chunking. That means organizations can get the right data where it needs to be without creating more copies and unnecessary data movement.
Then, as you move into training and inference, the focus shifts to getting the most out of the infrastructure. Everpure FlashBlade is designed to deliver the bandwidth and parallelism needed to keep GPUs productive, while Pure Key Value Accelerator (PureKVA) helps pre-stage context directly into GPU memory so GPUs spend less time waiting for data.
We’re also introducing an Intelligent Token Optimization reference architecture using open weight models. That gives organizations more control over where and how they run inference, while helping optimize token consumption and reduce unnecessary dependence on external API providers.
The common thread across all of this is efficiency. If you can find the right data, understand it, prepare only what you need, keep your GPUs productive, and avoid unnecessary tokens and data movement, you can get more useful work out of the infrastructure you already have. This is an important part of making the economics of AI more predictable as workloads move from experimentation into production.
VMblog: What are the most common roadblocks companies face when trying to move AI out of the pilot phase and into full production, and how do these capabilities solve them?
Gupta: The biggest issue we’re seeing is that the models aren’t necessarily the problem. The enterprise data environment and access to the underlying context of the data.
Companies have data spread across applications, storage systems, clouds, and different business environments. They often don’t have a clear picture of what data they have, where it is, who can access it or which information is appropriate to use for a particular AI workload. That creates problems with governance, security, data preparation and ultimately cost.
That’s why we’re approaching the problem as an end-to-end journey: discover the data, understand it, prepare the right information, and then support training and inference.
File Edition helps with that first step by giving customers a way to understand their data estate without having to inspect the actual data within the file. Context Edition goes deeper by understanding the contents and relationships within the data.
Then the data plane and infrastructure capabilities help customers actually run those AI workloads efficiently. So we’re addressing the friction before AI reaches production, as well as what happens once it gets there.
VMblog: For companies concerned about growing hardware footprints and energy consumption, how does the platform help reduce storage and resource overhead?
Gupta: There are a couple of pieces to this. First, better data intelligence means customers don’t have to treat every piece of data the same way. If you can identify stale data, redundant data, and the data that actually matters to the business, you can make better decisions about what should be retained, moved or deleted. The goal is to stop spending resources treating the entire data estate as equally valuable.
Second, we’re improving the efficiency of the infrastructure itself. DeepReduce continuously looks for similarities within storage blocks, including in data that traditional deduplication has difficulty reducing. That allows customers to get more usable capacity from the infrastructure they already have, rather than continually adding hardware.
And with PureKVA, we’re also focused on resource utilization on the AI side. If GPUs aren’t sitting idle waiting for data, you’re getting more work from the compute you’ve already invested in.
So the broader idea is not simply “buy less hardware.” It’s to make the entire data and AI infrastructure more productive, from how much data you retain to how efficiently you store it to how effectively you use expensive AI compute.
VMblog: Looking at the bigger picture of where the industry is heading over the next few years, where do you see the concept of ‘Data Primacy’ changing the relationship between traditional IT storage companies and enterprise AI developers?
Gupta: I think the relationship is going to become tighter because enterprises will have to manage “data as technology” which will require data to be liberated from applications and the context to persist with the data at source, generally the storage device.
Historically, applications have owned and kept data with their own definitions. Your finance data lived in your finance application, your sales data lived in your sales application, and as applications multiplied and you needed those systems to work together, you had to handle the complexity of integrating the data and context between them. That model has created a huge amount of fragmentation and integration work across the enterprise.
AI is putting more pressure on that model as agents need to work across data that is spread across applications, warehouses, and other systems. Much of the context they need is trapped inside those systems, you can see this in the way different platforms are approaching AI and the companies that are housing them. Everyone has a piece of the context, but no one has the whole picture.
That’s where we see data primacy as an inversion of the traditional application architecture. Instead of moving and copying data to fit the application, you can create shared context around data wherever it sits and allow applications and AI workflows to use that data in place. That reduces integration and data movement while giving organizations more coherence and control over their data.
For AI developers, that means they can build workflows that plug into data across the enterprise rather than having to recreate the data layer for every application or agent. And for infrastructure companies, it creates a much broader responsibility: helping customers maximize the value of their data wherever it sits, while preserving the context, governance, and ownership of that data.
That is also why we believe storage has an important role to play, moving from just storing the data efficiently to also managing the data effectively. Data and its context needs to persist with it so that AI agents can continually learn from and work with data. This means that context can’t disappear every time the data moves between systems. Storage becomes part of that persistent memory, helping preserve not just where data lives, but what it means and how it can be used. Storage systems become the foundation for delivering the right storage and data context to enable customers to achieve the promise of data security, data residency, and data sovereignty.
That’s what I think Data Primacy ultimately represents: moving data from something applications happen to consume into something the entire enterprise architecture is designed around the enterprise’s data.
##
