DSX and a metadata engine. Anvil is a thing.
It can host its own storage, or it can plug into existing storage namespaces.
Tier 0
Info
The following are notes I took from a webinar on 2025-07-31.
The Hammerspace Tier 0 pitch is:
- It’s faster and cheaper than FSxL/AMLFS
- …but the cost comp seemed more like a marketing number than a real number
- …they placed zero value on the “managed service” part of the FSXL/AMLFS services
- It has a synchronous namespace which is different from the object tiering in Lustre HSM
- …but the namespace is not synchronous when instantiating Tier 0; it takes “minutes”
- …and it appears that once synchronized, Hammerspace owns the namespace and you cannot synchronously mess with the object tier namespace without breaking things
- No proprietary client
Tier 0 is compared to shared storage, not to other products that use the same architecture such as NeuralMesh Axon or Lustre’s LPCC. For example, they championed their time to deploy by citing “deploying 20 PB of Tier 0 capacity in 1.5 days,” which translates to instantiating a file system across 625x Hopper HGX nodes. They claimed $7M in capex savings by (I assume) calculating how much 20 PB of data-protected flash(?) would’ve cost through some competitor’s shared storage solution(?).
From this, it seems like their target customers are people who buy GPU server reference designs, pay for the SSDs in them, but are not sophisticated enough to understand how to use them.
Although positioned for enterprise AI stuff (RAG, agentic, and the usual suspects), their success seems to be in media and entertainment (geodistributed SMB), which is where Hammerspace’s traditional value has been greatest.
The way it works was described as follows:
- Deploy “Hammerspace software”
- Requires metadata servers + data mover nodes in addition to the node-local storage on GPU servers. I think this is different from NeuralMesh Axon which doesn’t require separate control-plane nodes.
- Doesn’t require a proprietary Linux client since it uses pNFS v4.2 with Flex Files (I think?)
- Bind an NFSv3 mount to the global namespace
- “Sssimilate metadata” - so does it make a shadow namespace?
- It takes “minutes” for the Hammerspace namespace to synchronize to the backing store, which can be any NFSv3 (or object?) storage system.
It sounds like Hammerspace creates a shadow namespace, which introduces the age-old problem of a global namespace forcing all interactions to go through the global namespace instead of maintaining utility of the original underlying data sources. So introducing Hammerspace Tier 0 on top of an existing data source seems to lock you into using Hammerspace forevermore?