Glossary
Software-defined storage
Software-defined storage runs the functions that once lived inside a storage array, such as data protection, pooling, snapshots and replication, as software on standard servers. Hardware and software are chosen and bought separately, which changes refresh economics and moves much of the responsibility for integration toward the buyer.
What separating the software changes
A traditional array arrives as controllers, drives, firmware and software from one vendor, and the whole unit is replaced at end of life even when the data on it is fine. Separating the software changes three things. Servers and drives are bought at market prices from more than one supplier. The system is refreshed a few servers at a time, so hardware generations overlap and no single cutover moves all the data. And provisioning, monitoring and expansion run through APIs, which brings storage automation within reach of the same tools that manage compute.
Delivery models
| Model | Hardware | Support | Typical use |
|---|---|---|---|
| Software on listed servers | Bought separately from a compatibility list | Split between software and server vendors | Large object and file estates, backup repositories |
| Pre-integrated appliance | Standard servers shipped with the software installed | One vendor for both | Teams that want array-style support |
| Hyper-converged | Same servers run virtual machines and storage | Usually one vendor | Branch sites and general virtualization |
| Cloud instances | Virtual machines and disks from a provider | Provider plus software vendor | Extending a software stack into a public cloud |
Who answers when something breaks?
Integration ownership is the trade. When a drive firmware fault corrupts data, the software vendor and the server vendor can each point at the other, while an array vendor owns the whole stack and answers for all of it. With software-defined storage, the split is settled before purchase: who supports which layer, and who leads when a failure crosses between them. Patching follows the same line. Operating system updates, firmware and drive swaps usually sit with the team running the servers, and the network between them is designed as carefully as the storage, since replication and rebuilds travel over it.
How it relates to neighbouring terms
Software-defined describes where the storage logic runs. Most software-defined systems are also scale-out, growing by adding servers, and distributed, spreading data across them. Storage virtualization is a different approach: it places a mapping layer over existing arrays and keeps them, where software-defined storage replaces the array with servers. It is a common foundation for a private cloud.
Frequently asked questions
Does software-defined storage run on any hardware?
No. Vendors publish compatibility lists of tested servers, drives and network cards, and configurations outside those lists are a frequent source of avoidable incidents.
Can software-defined storage match an array for performance?
For capacity and throughput workloads it commonly does. For the lowest-latency block workloads, purpose-built arrays remain common.














