BeFS wasn't a database. It had indexed queries on EAs and they had the habit of asking application files to add their indexable content to the EAs. Internally it was just a mostly-not-transactional collection of btrees.

There was no query language for updating files, or even inspecting anything about a file that was not published in the EAs (or implicitly do as with adapters), there were no multi-file transactions, no joins, nothing. Just rich metadata support in the FS.

Yeah I am talking more deep architecture, and BeOS is more notable here mostly on just the user-interface level.

However, I think it is reasonable to think that with way more time and money, these things would meet up. Think about it as digging a tunnel from both sides of the mountain.

Microsoft poured at least $100M into this hole with nothing to show for it.

That doesn't disprove anything for me. It just says POSIX DOS lowest common denominator network effects are a hell of a drug.

Whenever we're talking about interfaces, coordination success or failure is the name of the game.

What problem do you think a DB-as-filesystem solves? The only obvious one that makes any sense at all is cross-file transactions.

The filesystem is a bad database

Directories are a shitty underpowered way to organize data?

No good transactions

Conflation of different needs such as atomic replace vs log-structured

I would like to use a better database instead.

Would you pay 50x performance decrease?

No, and I would also not need to.

Windows does something similar with Explorer today when you open a folder that has mostly music files in it.