I have just had interesting discusion with an astro guy who developped a database backend for his astro system. He stores FITS files from his sessions in a firebird SQL database. This enables him to index variables from FITS headers and manage the images in a way that is beyond what one can get from a simple file based storage.
I must admit that I love the idea. What do you think people? Is it the case that such a feature would be of interest to anyone? Jasem, is it something you would consider in the future releases of Ekos?

That sounds outside the scope of both INDI/Ekos since Ekos does not perform any processing so what use is the FITS SQL database for?

We could use it as an alternative storage engine compared to file storage. This might be a good starting point for other developers to work on separate viewers and processing engines e.g. cross-session analysis of images and their content. The idea comes from a guy that discovered a few supernovas using such an engine so I thought it might be worth considering.

Sounds like it is outside the scope of indi/ekos but its very interesting.

Here is another idea....
Rather than using a relational DB for storing files, seperate the 'data' and 'metadata'. In my experience with hadoop based technologies this is the approach used.
The files still sit on a filesystem (be it a HDFS distributed one or a local one or whatever) and the metadata is separated out into either a relational database or something else like mongo-db or even elastic search. Of course the metadata points back to the path where the data is and has to be updated by any pipelines that process the data too.

UPDATE: when I say metadata I mean the fits headers in this case....

Yes, you're right. It makes much more sense than storing the binary data in the database. It also means that it's all about developing separate "file parser" which would read the metadata from files stored by INDI/Ekos in a standard directory. It makes it much simpler than embedding it into Ekos.