As enterprises seek to leverage new data sources to improve existing business processes or completely transform their business models, new application requirements include the ability to incorporate multiple types of data models, i.e., document, key-value, and object, etc. – in addition to relational. The trick is to add data models without adding IT complexity.
While NoSQL databases were gaining popularity, enterprises adopted polyglot persistence. This means they would deploy unique data stores for each type of data model – document data in a document database, key-value data in a key-value database, and so on. As you add more data models to your application landscape, you can imagine the complexity of trying to manage things like data transformation and data lineage. This goes against the principle of keeping things simple.
In response to market needs, NoSQL vendors began to offer the ability to store multiple data models in a single, integrated back-end database – thus the introduction of the term “multi-model database.” The benefit is a less complex architecture plus improved data consistency.
If we begin with the premise that modern applications need a multi-model database at its foundation, the new ask is to support multiple workloads. A multi-workload database supports the ability to process transactions and analytics concurrently. Just as we saw with the multi-model database history, organizations had implemented workload-specific databases – ones that specialized in online transaction processing (OLTP) and others that specialized in analytics, or online analytical processing (OLAP).
Add this complexity to your polyglot persistence, and what do you get? A mess.
Gartner describes the multi-workload database as a hybrid transaction and analytical processing (HTAP) database. The notion that you can eliminate the need for an OLAP database and run analytics on the same database as transactions is growing in popularity. The value proposition is the same as multi-model: simpler architecture, lower overall management and maintenance costs, etc.
Let’s take this one step further. Now think of the scenario where you need to process transactions for both relational and document data sources while running structured and unstructured analytics to guide your application to process the transaction in an optimal way. You could either have multiple databases for processing different data sources and multiple analytical databases for structured and unstructured data – or you could have a multi-model, multi-workload database.
Rather than adding complexity, one should strive for elegant simplicity by following the KISS principle – keep it simple! The benefits include drastically lower costs, because it requires significantly fewer resources to support applications. Fewer moving parts is not only easier to manage; it also naturally lends itself to higher performance, higher reliability, and scalability.
As the number of new data models introduced into the market continues to grow, and as our customers want to add them to their applications, we plan to help them avoid polyglot persistence – by keeping things simple.