DAOS: an object store designed around non-volatile memory

What DAOS is and what it is for

DAOS stands for Distributed Asynchronous Object Storage, and the README describes it as an open-source software-defined object store designed from the ground up for massively distributed non-volatile memory. The design premise is specific. It takes advantage of next generation NVM technology such as Storage Class Memory and NVM express, meaning the storage tier is assumed to be fast and persistent, not a fast cache in front of spinning media. The problems it aims at are the ones that show up when you build a storage system on that kind of hardware: how to keep the network from becoming the bottleneck, how to survive a node failure without losing data, and how to keep a large cluster from being expensive to run. The intended users are storage engineers and platform teams at organisations with NVM or NVMe fleets, and the project is a Linux Foundation project, which is the relevant governance fact for anyone considering it for production.

A key-value interface with transactional, non-blocking I/O

The data model is a key-value interface, and the access pattern is described in two technical terms that carry most of the design. Transactional I/O means operations are grouped so that a failure part way through does not leave the store in a half written state, which is what you need when a job can be killed at any point. Non-blocking I/O means the application is not held waiting for the storage layer to complete an operation, so a process can keep working while data is in flight. Against commodity hardware, the README also lists advanced data protection with self-healing, end-to-end data integrity, fine-grained data control and elastic storage to optimise performance and cost. The through-line is that each of those features depends on the storage system knowing about the media and the fabric underneath it, which is why DAOS is written as a full stack rather than as a library layered over an existing filesystem.

Client libraries, storage engine and control plane in one repository

The repository is not just a library. The project description calls it a storage stack made of client libraries, a storage engine and a control plane, and the tree reflects that structure: a src directory for the implementation, a control plane with a vendored Go dependency tree, a deps directory for third-party build dependencies, a design directory for the design documents, and documentation sources under docs with mkdocs configuration at the root. The build is driven by an SConstruct file, so the build tool is SCons, and the Python requirements files separate what is needed to build DAOS, to run the functional test suite, to run unit tests and to run the linting tools. That separation is a sign of a project with a real test culture rather than a script. The README itself does not contain a build or install recipe, so the practical entry point is the documentation site, and the tree tells you what to expect once you get there.

How the parallel filesystem differs from the object store underneath

The interfaces are the part of DAOS most people meet first, and the list is broader than the object store label suggests: a parallel filesystem, a Hadoop and Spark connector, TensorFlow-IO, native Python dictionary bindings, HDF5, MPI-IO, and more to come. The difference in approach against a conventional filesystem is the point. Rather than extending POSIX semantics over a block device, DAOS presents a key-value interface with transactional semantics and lets a parallel filesystem sit on top as one of several views of the same engine. The same store can therefore be consumed by a machine learning pipeline through TensorFlow-IO, by an MPI program, by a scientific workflow through HDF5, and by a Python script through plain dictionary bindings, without a separate system being deployed for each. The trade-off is that a POSIX dependent application that expects every filesystem behaviour is not going to get it from the object interface, and the parallel filesystem is a specific component with its own operational requirements rather than a free substitute.

Getting hold of it: documentation, wiki, forum and tracker

There is no installation command to copy. The README points to the online documentation at docs.daos.io and to the project wiki, and the documentation is where the installation and deployment guidance lives. Support has three distinct channels, and picking the right one saves time. Questions go to the user forum on groups.io. Bugs go to the issue tracker at jira.daos.io, and the project asks for a test case to reproduce the issue where one applies, plus the debug logs, with a troubleshooting page linked for finding them. Day to day discussion happens on the Slack workspace, and joining the community mailing list sends the invitation to that workspace. A Linux Foundation project with a public forum, a public tracker and a chat room is a good sign for a system you intend to depend on.

A release stream made of release candidates

The version history is the part to look at before you plan a deployment. The three most recent tags are v2.8.1-rc2 published on 2026-09-24, v2.8.1-rc3 on 2026-10-01 and v2.8.1-rc4 on 2026-10-19, so the current line is a sequence of release candidates rather than a published stable 2.8.1. The last push was on 2026-10-20, so the tree is moving fast and the candidate tags land close together. For an evaluation that is convenient, since you can pick the candidate you tested. For a production plan it is a question to answer first: whether a non-candidate release of the version you want exists, and what the project says about moving from a candidate to a final release. Continuous integration signals in the tree point the same way, with workflows for the main build, a Coverity scan, a codespell spelling check, Doxygen documentation and a Trivy vulnerability scan, which is a broad set of automated checks for a system of this size.

Licensing and what to verify before you deploy

DAOS is licensed under the BSD-2-Clause Plus Patent License, and the README points to the LICENSE and NOTICE files for the details. GitHub itself classifies the licence as something it cannot categorise, which is a common artifact of licence files that add a patent clause to a familiar permissive grant, and it is a reminder to read the actual file rather than the badge. The practical implication is that a permissive grant with an explicit patent provision is usually straightforward for commercial use, including inside a product, but the exact obligations are a question for your own legal review rather than for this article. Beyond the paperwork, the checks worth doing are technical. Confirm the hardware assumptions hold, because a design aimed at Storage Class Memory and NVMe is not interchangeable with a spinning disk deployment. Confirm which of the listed interfaces you actually need, since each one adds a component to operate. And confirm the operational surface, since the control plane, the client libraries and the third-party build dependencies all arrive in the same tree.

Editorial conclusion

DAOS is a serious candidate for an organisation that already runs large NVM or NVMe storage and wants a key-value object store with transactional semantics on top of it, and it is a Linux Foundation project with the governance to match. It is the wrong choice for a team that needs a filesystem today, that runs on spinning disks only, or that wants a stable release rather than a release candidate. Before committing, read the online documentation for the current installation path, check the tags to see whether a non-candidate release of the version you want exists, and read the LICENSE and NOTICE files, since the BSD-2-Clause Plus Patent terms are what you will be shipping under.

Frequently asked questions

Official sources

1. daos-stack/daos on GitHub
2. Issues
3. Project website
4. README
5. Releases