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, which will enforce consistency, unlike the more flexible (and consequently more dangerous) NoSQL products where these types of rule must be performed in the terminal. But when we're talking about atomised data with no dependencies such as a vol surface, this consistency enforcement is probably not even going to be used. 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, journaling, redundant servers, everything you might need for multiple layers of security, including incremental backup to cloud. Redis of course could be problematic in that respect. But the established NoSQL databases are safe and reliable, indeed possibly more safe if you do not have a skilled DB administrator who knows how to get a complex SQL system up and running again on failure.
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.