It all depends what your aims are. We have a well-defined set of data we need to keep, including intermediate processing steps. We don&#x27;t need headers, structured arrays, or any weird esoteric object types. (The author is my colleague.)<p>We can get by just fine with:
- N-dimensional arrays stored on disk
- Key-value metadata associated with those arrays
- A hierarchical data structure.<p>We&#x27;ve been very happy so far replacing HDF5 groups with folders (on the filesystem), HDF5 datasets with flat binary files stored on disk (just as HDF5&#x2F;pretty much any other format stores them - each value takes up 1 or 2 or 4 bytes, and your filesize is just n_bytes_per_value * n_values), and attributes by JSON&#x2F;XML&#x2F;INI files. If I sent you one of our datasets, zipped up, you&#x27;d be able to make sense of it in a matter of minutes, even with no prior knowledge of how it was organised.<p>It is very tricky to build something that works reliably across all systems, but, thankfully, filesystem designers have done that job for us. And filesystems are now at a point where they&#x27;re <i>very good</i> at storing arbitrary blobs of data (which wasn&#x27;t the case when HDF was founded). Filesystem manipulation tools (Windows Explorer &#x2F; Finder &#x2F; cd&#x2F;cat&#x2F;ls&#x2F;mkdir&#x2F;mv&#x2F;cp&#x2F;[...]) are also very good and user-friendly.<p>There isn&#x27;t really anything we miss about HDF5 at all. Perhaps if your project has spectacularly complex data storage requirements (as to your examples: metadata&#x2F;headers are easily stored in JSON), but there&#x27;s no other project I know of that actually relies on an HDF5-only feature and couldn&#x27;t trivially use the filesystem instead.