Max Mortillaro and Arjan Timmerman set up their EMEA-focused Osmium Data Group analyst firm in March. They published a data protection Trendscape report in November (Trendscape is the firm’s flagship market research document). Now Osmium has a new TrendScape, focused on primary storage, that it will soon publish. We asked the analyst firm some questions about how storage would pan out next year.

Blocks & Files: With virtually all file system suppliers supporting S3 and many supporting Nvidia’s S3 Direct for Objects, how do you see the future for stand-alone object storage suppliers?

**Osmium: **We think the nuance is in the implementation. All of them support some flavor of the S3 protocol, but they may not support all the extensions of the S3 protocol. Other points revolve around performance optimization and concurrent multi-protocol support. These do not matter for customers that need basic object storage capabilities, but for customers seeking an optimized object storage solution, we believe standalone object storage suppliers will still stay around for a while.

We can think about object storage systems tuned for performance or optimized for capacity. These will almost always beat a generic-purpose storage system that offers object storage on top of other capabilities, for example file & block. For example, small departmental uses cases or proof-of-concept activities would be fine with S3 buckets provided out of a unified storage array, but moving into production is likely to require a shift to a dedicated object storage system.

We’ve even been through troubleshooting at customers where one specific application would not work out of a NetApp AFF S3 bucket and only started working once the bucket was provided via a NetApp StorageGRID appliance.

To conclude, there is going to be some encroachment from unified primary storage solutions as well as file/object storage, but we do not think that standalone object storage is going to entirely disappear.

Blocks & Files: How will the HCI/hypervisor market develop?

**Osmium: **For us, Broadcom’s acquisition of VMware has fundamentally changed the game in that space, especially when you look at what VMware has become today. VMware Cloud Foundation is built into the original SDDC vision, but forces the entire stack on customers, regardless of which part they want to consume, and this obviously comes at a price.

You might think that Nutanix is the obvious alternative, but it’s not necessarily that simple. Pricing is not dramatically more competitive. You might get similar price points and perhaps get a bit more out of the stack, but the offering is still compartmentalized. You need add-ons for automation, add-ons for other capabilities, and by the time you assemble the full stack, the cost difference versus VMware is not as significant as many would expect.

In the end, we see both solutions as more or less equivalent from a cost perspective. There are other, less known, options that say to be more open-sourced, like Scale Computing – which excels in the Edge space, Starwind or Stormagic, and larger solution providers like HPE, Sanfor or Dell.

HCI still makes sense if you want to optimize space, and you want a tightly integrated compute-and-storage stack with simple deployment and operations.

You can achieve similar, if not better efficiency today using an all-flash array or even an entry-level hybrid array. We’re thinking about lower-end systems from vendors like Pure Storage or NetApp, systems that are more than sufficient for SMB and mid-market use. In that model, you avoid deep lock-in to a VMware or Nutanix ecosystem, and you can run alternative hypervisors, whether that’s Xen, Proxmox, or something else.

Our conclusion is that we wouldn’t say we are at the beginning of the end for HCI, but we are questioning its relevance for the future. There is still value in running such a stack, but there are now better ways to deliver infrastructure at a more efficient price point.

Blocks & Files: How do you see legacy RDBMSes developing to support AI LLM and agent needs? Will knowledge of graph technology play a role?

**Osmium: **We’ll be upfront and say that we are no experts in these technologies. That said, we do think that if you are trying to extend legacy technology to support something that is fundamentally new or different, you are probably going to run into problems.

We can imagine some form of gateway or proxy layer that tries to bridge the gap, something that allows legacy systems and newer AI-driven technologies to talk to each other. We are not describing that perfectly, but the idea would be a bridging technology that sits in between.

The question then becomes: why would you want those systems to talk to each other in the first place? The only real reason that comes to mind is what we would call stratification in enterprise IT. New technologies tend to get added as layers on top of existing ones, but the lower layers don’t disappear. They just keep accumulating, almost like geological layers in an experiment. That’s often how enterprise technology evolves.

From our perspective, if you’re experimenting with AI and LLMs today, it probably makes more sense to use native tools, vector databases, purpose-built platforms, and so on rather than trying to retrofit something ancient. We can see why some vendors might push legacy extensions and make a lot of money selling them to organizations that don’t necessarily have a clear rationale for why they need them.

That said, there may well be valid business use cases for this kind of integration. We just don’t feel well-positioned to give a definitive answer to that.

Blocks & Files: How do you see storage system admin interfaces developing? Will global namespace and fleet management and AI performance/security tools become table stakes? How might natural language interfaces to AI agent technology get introduced?

**Osmium: **This is a very interesting question. We are about to release a new TrendScape, our flagship market research document, focused on primary storage. Many of the aspects you mention, such as global namespace, fleet management, and operational tooling, are explicitly part of the evaluation criteria – and we acknowledge they go beyond the scope of primary storage.

Starting with global namespace and fleet management: we think global namespaces are essential in modern storage systems. You want to see and manage data globally across the organization because of the benefits that brings, whether that’s around data management, operational visibility, or efficiencies such as compression and deduplication.

Fleet management is equally critical, and it ties directly into other key aspects such as security. Data security posture management needs to be embedded into fleet management. You need to understand the full state of your environment, health, performance, configuration, and security posture, across the entire storage platform.

Vendors should also be delivering systems that are secure by default. That means sensible, hardened configurations out of the box, not relying on customers to “do the right thing” later. Administrators need to see their storage environment not as isolated systems, but as a single living organism. That end-to-end visibility is especially important when dealing with malware, ransomware, or other security incidents.

On the question of AI performance and AI security tools becoming table stakes, we think we’re not fully there yet. Some vendors have had machine learning–based capabilities in place for quite some time, and in some cases, they work very well. There is, however, a tendency to label everything as “AI,” just as in the past some basic statistical approaches for analytics were rebranded as machine learning. So, some realism is needed here.

As for natural language interfaces and AI agents, we think this is inevitably coming, and our expectation is that these systems will operate in a constrained or out-of-band mode. Some vendors already do this in adjacent areas, such as data protection, where admins can interact with a chatbot-style LLM. In storage, that could mean read-only access to performance metrics, health data, fleet status, and similar telemetry. These systems could help administrators query data, compare states, identify trends, and assist with troubleshooting. Some of this already exists today.

Where we remain skeptical, is allowing these interfaces to perform actual actions in the environment. First, there is a trust issue. Given the quality and unpredictability of some LLM outputs today, it would be a bold move to let such systems directly modify production infrastructure. We’ve already seen real-world cases where poorly constrained AI-driven automation has caused serious damage, including accidental deletion of production databases.

We struggle to imagine many CIOs, CTOs, or heads of IT approving a system where natural language input could trigger destructive operations like deleting file systems, volumes, or datasets. That runs counter to core principles around data immutability and risk management.

The second major concern is security. If administrators can interact with infrastructure through an AI layer, that entire stack needs to be secured from end to end. Any weak point, whether authentication, authorization, or implementation, could potentially be exploited. An attacker could manipulate or bypass controls through the AI interface itself. Even with strong measures like MFA in place, poor implementation could make the AI layer an attack vector.

For these reasons, we don’t see fully autonomous, action-taking AI interfaces becoming mainstream in storage administration anytime soon.

Blocks & Files: How will high-end, monolithic array technology (Dell PowerMAX, IBM DS8000, Lenovo Infinidat) develop, and will it withstand encroachment by scale-out, multi-controller node, mid-range storage?

**Osmium: **Our view here is that this is less a problem of technology encroachment and more a problem of trust and buyer confidence. That ties directly to the types of customers and industries these systems are targeting.

There is no doubt that scale-out storage architectures have matured significantly. After several years of analyzing the market, it’s clear that many scale-out systems are massively scalable, deliver strong performance, and are robust and reliable.

What’s holding them back from truly encroaching on high-end monolithic arrays is not capability, but trust. When organizations deploy these architectures, whether software-defined or fully productized appliances, the decision is rarely purely technical. In highly regulated and risk-averse industries, such as financial services, the tolerance for risk is extremely low.

In those environments, decision-makers tend to favor “safe bets.” Very few decision-makers want to be remembered as the person who made a bold architectural decision that later failed, especially in sectors where regulatory scrutiny and financial penalties are real.

So, while a customer might decide that their relationship with a particular vendor is no longer ideal, they might look at alternatives like IBM or Infinidat, but still stay within the established high-end, enterprise-proven segment. The likelihood of a sudden move to a fundamentally different architecture is relatively low.

Where we do see more openness to change is in organizations undergoing broader transformation, for example, those building more cloud-native applications or fundamentally changing how they design and operate IT. In those cases, the architectural shift itself creates space to consider newer approaches, including scale-out designs.

Overall, we think this will be a gradual evolution. High-end monolithic arrays still have good years ahead of them. They will continue to be challenged, but displacement is unlikely because trust and risk tolerance, not technology, remain the dominant factors.

Blocks & Files: VAST’s DASE architecture ideas are spreading. Witness HPE Alletra MP, NetApp’s AI-focused ONTAP development and, I think, Dell’s PowerScale Project Lightning. How do you see mainstream scale-out/clustered dual-controller storage systems developing? How will users benefit?

**Osmium: **We see VAST Data’s disaggregated shared-everything architecture as a genuinely innovative approach, and credit them for that. The fact that we now see similar ideas appearing elsewhere is a validation of those architectural principles.

Where it becomes interesting is when you compare these architectures with more mainstream solutions, such as dual-controller storage systems or traditional scale-out clusters. Ultimately, it comes down to use cases: the amount of data, the expected growth, and what you are trying to optimize for.

If we think about very large-scale deployments, massive capacity environments, potentially at rack scale, there are already solutions that scale very well within constrained form factors. Even though it’s not a perfect comparison, systems like Infinidat can deliver very large capacity within a single rack, with mature internal controllers and interconnect architectures. From the customer’s perspective, you don’t really need to worry about the internal fabric; what matters most is the external connectivity.

The same is true for other mainstream vendors. With disaggregated shared everything architectures, you need to think much more carefully about scale and external dependencies such as connectivity. These designs really start to shine when you are talking about multi-petabyte environments and beyond, tens of petabytes, hundreds of petabytes, potentially even exabyte-scale deployments.

There are clear benefits. The ability to scale storage independently of compute, to separate data and metadata, and to avoid unnecessary node additions can deliver much better efficiency and, in theory, lower $/GB (or, perhaps more suited, $/PB). But there are always trade-offs. You also need to understand how such an architectural shift impacts cost, complexity, and operations.

So, in terms of user benefit, the main advantage is more flexible and efficient scaling. But whether that benefit materializes depends heavily on scale, workload, and organizational context. It’s not a universal answer, and for many environments, more traditional scale-out or dual-controller systems will remain perfectly adequate.

That’s not a perfect or absolute answer, but our honest opinion.