For any data that is not strictly tabular and unchanging in schema, you should rule out SQL solutions. Option pricing fits that description in my experience, because high-liquidity stocks, currencies, or bonds, will have a far bigger set of strikes and maturities than lower liquidity instruments. Thus in a relational database you will have to have columns for strikes and maturities, with clunky joins everywhere, whereas in NoSQL such as Mongo, you can have an atomized "document" that has all the data associated with a timestamp, that is extremely rapid to query, and is also flexible for meta-data. Who hasn't found the need to for meta data, even in financial time series? You'll be able to go back and systematically add new structures and substructures to your data without messing up the whole schema. 

My own experience with Mongo is very positive. Once you have familiarised yourself with its JSON-based query syntax, it's easy, and extremely fast on cheap commodity hardware. It's also massively easy to setup. That is definitely not the case for the relational databases on equivalent hardware. Another bonus is that you'll learn JSON - a very useful and widely use format for data that allows you to export "flat" data CSV-style, but can also do hierarchical nesting which can be really useful, without going to the overkill that is xml.

If extremes of consistency are what is necessary, then SQL is your bet. Stuff like: this salary *MUST* be linked to an *EXISTING* employee that is *NOT* on sabbatical. This type of rule can be embedded in the database. With Mongo or other Nosql, these types of rule must be performed in the terminal code, which is less reliable. But when we're talking about atomised data with no dependencies such as a vol surface, the design "fit" of SQL is overkill and comes with heavy burdens. Recall that SQL was designed for business logic in the 70s. 

Don't believe those who tell you Mongo or other NoSQL is not reliable when it comes to data safety. That is false. There are all the usual tools to guarantee writes, redundant servers, everything you might need. Redis of course could be problematic in that respect. But Mongo is not. 

Finally if your use case is only single-machine, then strongly consider HDF5. This will outperform and be better suited to a large financial data mining application than any of the database technologies. It has been designed exactly for what you require (massively fast, flexible queries and schemas) but of course it's not as strong for sharing.