File-based databases vs filesystem-based databases

[vicot]

Hi

as you probably know, some filesystems (like XFS, BtrFS, ZFS, etc) have advanced features (namely extended file attributes) that provide database-like capabilities. Practically, you can have a relational database managed by the filesystem itself. You can attach to a file as many metadata (read: tags) you want, and retrieve the files, make connections among them, create virtual directories, etc. simply by using the tag-like feature of extended file attributes. Basically, each file is a record, that can be linked to other files via multiple relational links.
Anyway, you probably already know all this stuff.

My question pertains to the suitability of a filesystem's database-like capabilities for different purposes.
Some people may wonder: what's the point of using the filesystem as your database, when you can conveniently store all the file-related 'tags' in a file-based database? This is a reasonable question, of course.
On the other hand, one may also ask: what's the point of using a file-based database to store file-related metadata, when you can use a filesystem-based database?

These two different methods of managing file-related metadata (tags) both accomplish pretty much the same thing (within certain parameters, of course), and yet I am sure that each method has some advantages over the other.

Could someone please explain to me in which cases it is better to use a file-based database and in which cases it is better to use the filesystem-based extended metadata capabilities? (again, the intended use is mainly for file tagging and file-linking and clustering).

I would really appreciate if you could also point out the strength and weaknesses of each method.

Thanks

vicot

[BigChimp]

Vicot: interesting post!

Actually, I'm not really aware of what modern Linux filesystems can do, so nice post.

For me, depending on the filesystem a user happens to have installed would be a massive disadvantage. Much easier to have the user install a certain database package (or even support a couple of them, e.g. Firebird and PostgreSQL).
Obviously, you would also lock your users into those platforms where those filesystems are supported (e.g. probably no Windows, OSX...)

Also, I'm rather an SQL afficionado (if all you use is a hammer, everything starts to look like a nail ), so I'd look for SQL support. However, I realize others may be more flexible

Of course, somebody could write an adapter for sqldb that encapsulates those fileystem properties - then a programmer will just see the filesystem as another database (good luck with writing an SQL parser etc though).

[marcov]

Could someone please explain to me in which cases it is better to use a file-based database and in which cases it is better to use the filesystem-based extended metadata capabilities? (again, the intended use is mainly for file tagging and file-linking and clustering).

A filesystem is still not a database, even if there are some properties that are similar. That metadata is to make searching easier, not to implement databases.
 
So if it is a database, use a database system. If you want to add metadata to files, use extended attributes.