If you’re a clever enough engineer, you can define a file system in terms of a database, as …

If I understand correctly, bcachefs, that new hot filesystem, is pretty similar to a database - maybe someone knows more about this.

Thats how Amazon made Aurora. Move all state onto the object storage layer which is also at the end of processing (you go through the lb, than frontend, than backend, than database and land on disk). Stateless is basically moving everything to the back. Im pretty sure google is doing the same thing/started with it. Also this makes it 'easily' scalable horizontal: As soon as you are able to abstract on object level, you can scale your underlying infrastructure to just handle 'objects'.

> there’s not really a difference between a database and a file system. That was the promise of WinFS back in the day, which would have been really something had MS managed to bring it to fruition. I still remember the hype from back then, in my opinion totally justified, too bad that things didn't come to be. I legit think that that project could have changed the face of computing as we know it today.

If you look up WinFS (which is a cancelled Windows file system originally intended to ship with Windows Longhorn), its basic principle is exactly that, be a database that happens to work as a file system. Not sure why exactly it failed, I assume that it just wasn't a suitable idea at the time given that most consumer devices (especially laptops) had very slow traditional hard drives, but in the age of NVMe storage, maybe it would be worth revisiting, assuming that Microsoft is still interested in evolving Windows in meaningful ways outside of better Ad delivery mechanisms.

You don't really need to be a clever engineer, there are pre-made implementations out there for you. For example if you have an Oracle DB, then it has a feature called DBFS that does this already: https://docs.oracle.com/en/database/oracle/oracle-database/2... You can instantiate a POSIX compatible FS using database tables, and then mount them using FUSE. From there you can export it via NFS if you wish. You can also export the FS via WebDAV and thus mount it over the network using the WebDAV support built in to Windows or macOS. If you want to work with the FS transactionally, you have to do that using PL/SQL. POSIX doesn't define APIs for FS transactions, so some other approach is needed. Because it's stored in the DB you can use all the other features of the RDBMS too like clustering, replication, encryption, compression and if need be, you can maintain indexes over the file content…

I disagree because querying is an important feature of most databases as usually conceived, so I think filesystems are only a subset of a database.

> there’s not really a difference between a database and a file system Having written an interface to FoundationDB in preparation to moving my app over to it, I couldn't disagree more. Even "has proper indexes" is not something we'd agree on. In my case, for example, I am extremely happy with the fact that my indexes are computed in my app code, in my language, and that I am not restricted to some arbitrary concept of database-determined "indexable fields" and "indexable types". Then there are correct transactions, versionstamps (for both keys and values), streaming large amounts of data, all of that in a distributed database, it's really nothing like a filesystem.

I remember back in the 80s thinking that a file system that was organized like a relational database¹ would be a really wonderful thing. Files could live in multiple places with little difficulty and any sort of metadata could be easily applied to files and queried against. ⸻ 1. I had read the original paper on database normalization over the summer and was on a database high at the time. I was young.