A file system as a database is one of those things that makes a good pitch but falls down pretty hard once you try implementing it. It falls apart faster if you've got to touch the Internet.

The first and biggest problem is that different types of files have metadata they consider to be important. Author and editor information useful for collaborative editing in a Word document is immaterial to a static raster image saved with a lossy codec. So your database ends up with dozens to hundreds of schemas to store metadata. You still need to serialized and deserialize metadata on files going out or coming in. If some unrelated application (not the authoring application) went and edited the database, which metadata for that file is canonical? The world may never know.

If you're building some metadata management database that's also storing binary blobs on addressed blocks on a disk, you might as well use a traditional file system and have a read-only database on top.

That way the file system stores bytes. An application unrelated to authoring can safely shuffle those bytes over the Internet. It's up to an authoring/editing application to store appropriate metadata.

The files themselves always have the canonical metadata and the read-only database for finding/organizing the files can just update when it's notified of a change in the file.

The database can focus on database things and the file system can make sure bytes go where they need to be. This also gives the flexibility to swap out either the file system or database at any time. This is the way Windows and macOS went and how many Linux DEs work.