I suggest to take a look into cqrs (Command Query Responsibility Segregation) pattern that was initially introduced by Greg Young . Also you can read here .

This approach involve to have two databases: read and write. Write database is used as primary write store and read - database for querying. Read database can have denormalized data. For example if you have article you can embed author information in it as well for quick display on ui. And in general nosql database good fit for read storage.

In your case primary normalized database can be in sql and read database can be in mongodb.

In general this approach good fit for high traffic systems. There is open source implementation of it -- ncqrs .

Also this approach in roadmap of microsoft for 2012 year.

from me: I am using this approach more than one year and giving to it my personal vote up.

Migrating to a database like MariaDB Enterprise (on-prem or in the cloud through SkySQL) could be an interesting option to evaluate. MariaDB has multiple pluggable, purpose-built storage engines configured per table and with cross-engine join support (joining tables that use different storage engines). Some (but not all) of these engines are:

• ColumnStore: For big data and analytics. This is equivalent to having an index on every column of the table but without the hassle of having to deal with indexes. It scales horizontally supporting ad-hoc queries on hundreds of billions of rows in real time.
• Aria: For read-heavy workloads that don't need transactional capabilities but where read performance is critical (for example, shopping carts, reviews, ratings).
• MyRocks: For write-heavy workloads that need better compression and less write amplification than other storage engines or databases.
• InnoDB: What you need 99% of the time. It supports compression, encryption, transactions, instant schema changes, multi-primary clustering with synchronous replication, and more.
• MEMORY: For storing data in memory instead of disk. Ideal for read-only caches, and temporary data.
• CONNECT: enables MariaDB to access external local or remote data (MED). This is done by defining tables based on different data types, in particular files in various formats, data extracted from other DBMS or products (such as Excel or MongoDB) via ODBC or JDBC, or data retrieved from the environment (for example DIR, WMI, and MAC tables)
• Spider: Supports partitioning and xa transactions, and allows tables of different MariaDB instances to be handled as if they were on the same instance.

Here you find advice on how to choose the right storage engine: https://mariadb.com/kb/en/choosing-the-right-storage-engine/

There is also MariaDB Xpand which almost linearly scales reads and writes while keeping ACID compliance, and MaxScale, a database proxy that enables automatic failover, read-write splitting, transparent masking, exporting and importing database events to and from Kafka (CDC), and even use MariaDB as if it was a MongoDB database (you can connect an application that uses MongoDB drivers and store the data in MariaDB instead of MongoDB itself which allows you to join data from MongoDB apps with data in relational tables using a single SQL sentence).