I'll start with an anecdote. Scroll down if you want just the conclusion.<p>I work in test automation. In the general storage area. I worked for some years with a distributed filesystem (think something like Lustre, but modern and fast), then worked with something like DRBD, but, again more modern. Not sure how fast (never ran any benchmarks on DRBD). I had to deal with filesystems like Ceph's filesystem, BeeGFS...<p>Anyways. When I worked on the DRBD analog, let's call the product "R", one of my tasks was to figure out how well would a database work on top of R. Well, "database" is a very broad term. I figured I'd concentrate on using couple of well-known relational databases. PostgreSQL turned out to have the most to offer in terms of insight into its performance. Next, I'd have to find a suitable configuration for the database. And that's where things got really complicated. To spare you the gory details: the more memory you can spare for the benefit of your database server -- the better, the more you can relax the requirement of synchronizing with persistent storage (i.e. fsync and friends) -- even better.<p>In the end of the day, I had to abandon this kind of testing because, essentially, if given enough memory, or enough replicas (allows not to care about destaging to persistent storage) the bigger numbers I could produce, which made the question "how well does R compare to a plain block device?" irrelevant.<p>---<p>Fast-forward to this article. It gives out a vibe of "filesystems are not efficient, if you re-arrange something in the logic of doing I/O you can gain more performance!". And that really reads like "10 things doctors don't want you to know!" advertorial. It's similar to the misguided idea I often encounter with people who aren't system programmers that "mmap is faster".<p>Now, understanding why "mmap is faster" is nonsense will help understand why benchmarking a database on top of a filesystem and comparing performance doesn't make a lot of sense. So, in order to properly compare the speed, we need to make sure we compare both good and bad paths. What happens when I/O errors occur when memory-mapping files and when using other system API? I invite you to explore this question on your own. Another question you need to ask yourself in this comparison is "how well does this process scale", on a single CPU, single block device, multiple CPUs single block device, single CPU multiple block devices... And on top of this, what if we consider Harvard architecture (to an extend, IBM's mainframes are it, at least there general I/O is separate from the rest of computing). In other words, what if our hardware knows "some tricks"? (Other examples include the kinds of drivers and protocols used to talk to the hardware and whether the storage software, even if running on top of a filesystem will know / be able to take advantage of these, i.e. NVMe allows big degree of parallelism, but will "mmap" be able to utilize that? Especially if multiple files are mapped at the same time?)<p>And, of course, there is a difference between what's been actually done and what guarantees can be given about the state of data during and after the I/O completes. And these details will greatly depend on the details of the specific filesystem being used. For example, if you wanted to write to the device directly (as in with "ODIRECT | OSYNC"), but the filesystem is something like ZFS or Btrfs (i.e. it needs to checksum your data beside other things), then you might get confused about what you are actually comparing (direct I/O would imply less I/O than is actually necessary to give durability guarantees that may not be given by an alternative storage).<p>---<p>So, a better title for the article would have been "It's possible to carve out a use-case, where SQLite works faster than a similar process designed to only use system API to access a filesystem". Which is essentially saying: you, the programmer, don't know how to use a filesystem as well as we do... And, in my experience, most programmers are clueless when it comes to using filesystem or any other kind of storage really. So, that's not surprising, but is still not as sensationalist as the original title.