Please keep in mind that one of the key design centers of a component file system is that your APL data is stored on a file. SQLite seems a perfect match for this use case. Using SQLite freed me from having to worry about all the details of writing an indexed file and ensuring that updates are done consistently even in the case of software or hardware failures. It's not that I couldn't implement all of those details in APL and C(++); it'd be a *lot* more work and subject to a lot more bugs in the near term. For this reason, SQLite is the ideal layer upon which to build a single-user component file system.
Regarding files: Take a look at component file systems on other platforms. They are, to the best of my knowledge, all backed by named files. Again, SQLite makes this possible because one database is one file.
Regarding resources: SQLite is a library that maps SQL interactions onto its database file. There is no server. There is no additional overhead in opening multiple SQLite databases.
Leaving the SQLite clarifications behind...
I've never seen anyone else layer a component file abstraction on top of a database server. To me, the main benefit of this would be the (potential) ability to share a component file from multiple APL instances in multiple locations. That's something that you can't do with SQLite unless you build a server to mediate connections, access rights and concurrency.
That said: What do you (Elias and Blake) see as the benefit of using a database server like PostgreSQL to host a component file abstraction, keeping in mind that you already have access to the underlying database? Or to phrase that differently: why use a component-file API when you really need the features of a database server?