* High risks of data corruption - HDF is not a simple flat file. Its a complex file format with a lot of in memory structures. A crash may result in corruption but there is no <i>high</i> risk of corruption. More over, if your app crashed, what good is the data? How can you make sense of the partial file? if you just need a flat file which can be parsed and data recovered, then you didnt need HDF in the first place. So wrong motivation to pick HDF. On the other hand, one could do a new file for every checkpoint &#x2F; iteration &#x2F; step, which is what most people do. If app crashed, you just use the last checkpoint.<p>Bugs and crashes in the HDF5 library and in the wrappers - sure, every sw has bugs. But in over 15 years of using HDF, I have not seen a bug that stopped me from doing what I want. And the HDF team is very responsive in fixing &#x2F; suggesting work arounds.<p>Poor performance in some situations - yes &amp; no. A well built library with a well designed application should approach posix performance. But HDF is not a simple file format, so expect some overhead.<p>Limited support for parallel access - Parallel HDF is one of the most, if not the top most, popular library for parallel IO. Parallel HDF also uses MPI. If your app is not MPI, you cant use Parallel HDF. If the &quot;parallel access&quot; refers to threading, HDF has a thread safe feature that you need to enable when building the code. If &quot;parallel access&quot; refers to access from multiple processes, then HDF is not the right file format to use. you could do it for read-only purposes but not write. again, not the right motivation to pick HDF<p>Impossibility to explore datasets with standard Unix&#x2F;Windows tools - again, HDF is not a flat file, so how can one expect standard tools to read it? its like saying I would like to use standard tools to explore a custom binary file format I came up with. wrong expectations.<p>Hard dependence on a single implementation of the library - afaik there is only one implementation of the spec. the author seems to know this before deciding on HDF. Why is this an issue if its already known?<p>High complexity of the specification and the implementation -<p>Opacity of the development and slow reactivity of the development team - slow reactivity to what? HDF source is available so one can go fix &#x2F; modify whatever they want.<p>seems the author picked HDF with wrong assumptions.<p>HDF serves a huge community that has specific requirements, one of which is preserving precision, portability, parallel access, being able to read&#x2F;write datasets, query the existing file for information of the data in the file, multi dimensional datasets, large amount of data to fit in a single file, etc.<p><a href="https:&#x2F;&#x2F;www.hdfgroup.org&#x2F;why_hdf&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.hdfgroup.org&#x2F;why_hdf&#x2F;</a>