Hitachi Vantara Brings Lakehouse Queries Directly Onto VSP One Object Storage
Hitachi Vantara's November 11, 2026 update lets VSP One Object query Iceberg, Parquet, JSON and CSV data in place — up to 5x faster on 80% fewer CPUs — plus new agent governance in iQ Studio.

Why it matters
- Announced November 11, 2026: VSP One Object can query Iceberg, Parquet, JSON and CSV data directly on the storage platform.
- Hitachi Vantara reports up to 5x faster analytical queries on 80% fewer CPUs from in-place querying.
- Small-object performance improvements support up to 5.5x faster data access for AI, analytics and S3 workloads.
- New four-node starting configuration lowers the entry point for AI-ready object storage.
- Hitachi iQ Studio adds a Model Gateway, governed MCP connectivity, ServiceNow support, and role-based access for AI applications and agents.
Hitachi Vantara announced on November 11, 2026 that VSP One Object can now run queries against supported open-format data directly on the storage platform, alongside a four-node starting configuration designed to lower the barrier to AI-ready deployments. The same update extends governance features in Hitachi iQ Studio, the company's software for building, deploying and governing enterprise AI applications and agents. Together, the two changes tie storage, analytics and AI governance into a single product story — and that framing matters, because enterprises increasingly stall on AI projects not for lack of models, but for lack of controlled, trustworthy access to their own data.
The announcement sits at the intersection of three layers that most vendors still sell separately: object storage, lakehouse analytics, and the software layer used to build and govern AI applications and agents. VSP One provides the data foundation for Hitachi iQ, which combines validated AI infrastructure with software that connects applications and agents to enterprise data, models, tools and workflows. The core idea is simple: keep data where it lives, query it there, and govern everything above it from one place.
What does the new four-node configuration change?
The headline hardware change is scale. A four-node configuration now serves as the entry point for AI-ready object storage, where earlier deployments presumably demanded a larger footprint to be practical. Hitachi Vantara positions this as a smaller starting point that lets organizations begin with less and grow as demand does — capacity scales with need rather than requiring a large upfront commitment.
Deployment is also meant to be simpler. The company says the initial setup is easier, which reduces the friction that often stops proof-of-concept projects from becoming production systems.
On performance, Hitachi Vantara reports that continued small-object performance improvements now support up to 5.5x faster data access for AI, analytics and S3 workloads. That number covers the read paths AI training and inference pipelines actually hit hardest — small objects are the shape of much of the metadata, documents and telemetry that feed retrieval and analytics systems.
The update also expands multisite replication and regional capabilities. These features keep data available, protected and accessible during disruptions. For AI and analytics workloads spread across sites, that addresses a different operational requirement than raw query speed: continued access to the underlying data when something breaks. Speed and resilience solve different problems, and the release covers both.
The takeaway: a smaller entry point plus 5.5x faster small-object access lowers both the cost and the risk of starting an AI storage deployment.
How do in-place lakehouse queries work?
The analytical centerpiece is direct querying of open-format data on the storage platform itself. VSP One Object supports queries against Iceberg, Parquet, JSON and CSV data — the formats that dominate modern lakehouse architectures. Hitachi Vantara reports up to 5x faster analytical query performance while using 80% fewer CPUs with the new capabilities.
Those are the two numbers worth holding onto: five times the speed, one-fifth the compute. Fewer CPUs for the same analytical work translates directly into lower infrastructure cost and less energy consumed per query.
The bigger structural claim is about data movement. Running queries on the object-storage platform removes the need to copy supported data into separate analytics systems. That, in turn, can reduce duplicate datasets, data pipelines and the infrastructure needed to maintain them. Every copy an enterprise eliminates is a pipeline it no longer has to build, sync and debug.
Why copies create governance problems
Hitachi Vantara's own explanation of in-place analytics identifies two governance problems with exported data, and both are worth spelling out because they get at why "just copy it to the analytics cluster" has quietly become a liability.
First, copies drift. An explanation generated from an older or differently filtered extract may not match the data behind a prediction. If you can't prove your explanation came from the same data as your model's output, your explanation is decorative. Analyzing the same data in place keeps the explanation and the prediction aligned.
Second, in-place analysis preserves a clearer lineage trail — the tables, columns and transformations that fed a model stay traceable. Lineage is what auditors, regulators and internal risk teams ask for first when AI outputs are contested.
The company grounds the approach in energy and medical workloads. Its examples include joining sensor time series with asset, outage and billing data for grid analysis, and querying imaging metadata and structured reports without duplicating sensitive records into separate analytics environments. The second example is pointed: in healthcare, every duplicate of sensitive imaging data is another surface that has to be secured and audited.
The takeaway: querying data where it already lives cuts duplication, keeps explanations honest, and keeps lineage intact.
What's new in Hitachi iQ Studio?
Hitachi iQ Studio is the enterprise software layer for building, deploying, managing and governing AI applications and agents. This release widens what it can reach and tightens how that reach is controlled.
New filesystem and NFS knowledge sources expand access to structured and unstructured enterprise data for retrieval-augmented generation (RAG). RAG supplies the enterprise context behind AI responses and agent behavior — and critically, the new sources work without requiring organizations to move or restructure all of that data first. For companies with terabytes of file-based data sitting on NFS mounts, that's the difference between a governance project measured in weeks and one measured in years.
A new Model Gateway governs access to both local and external models. That matters as enterprises increasingly mix self-hosted models with hosted ones: the gateway becomes the single choke point where access policy lives.
The release also adds:
- Governed Model Context Protocol (MCP) connectivity for linking agents with tools
- ServiceNow support
- Role-based access across enterprise AI applications and agents
- Observability across those same applications and agents
- Lifecycle management for applications and agents end to end
Taken together, these features extend governance beyond the storage layer into model access, tool connections and agent operations. An agent that can call tools through a governed MCP connection, reach only the models the gateway permits, and operate under role-based access with full observability is a very different animal from a script with an API key.
Chief product officer Octavian Tanase tied that scope to the company's production-AI message in one line: "AI strategy is now inseparable from data strategy." It's a short quote doing a lot of work — it's the thesis of the entire release compressed into six words.
The takeaway: iQ Studio now governs not just data but the models, tools and agents that consume it.
Why does this matter for enterprises?
For organizations moving AI from pilots into production, the practical consequence is a closer link between infrastructure decisions and governance decisions. Where the data lives, how it's queried, and who can reach which model are no longer choices made by separate teams on separate timelines.
Reducing data movement genuinely can simplify analytics and preserve lineage. But the approach's usefulness has a condition attached: access controls, observability and replication have to stay consistent as deployments grow beyond that initial four-node configuration. A governance model that works at entry scale but frays at production scale would undercut the whole pitch.
That's the question buyers should put to Hitachi Vantara and its competitors alike — not whether in-place querying works today, but whether the controls hold when the deployment is ten times bigger, spans more regions, and serves agents nobody has fully scripted. The November 11 release answers the first question with numbers; the second will be answered in production.
Source: unite.ai
More from Sophie Lindqvist
Show full bio
Staff writer covering regulation, policy and their impact on artificial intelligence and machine learning at AI In Context.
537 articles
Related articles
- Hitachi Vantara pushes AI analytics into storage with VSP One update
- ClickHouse Acquires Xata and Expands Into Postgres, AI Tooling
- TD SYNNEX takes its Destination AI program global for SMBs
- IBM Targets Mainframe Modernization With Z Atlas AI Package
- Confluent launches Streamhouse and Lightning Tables for AI agents