Multimodel v. Polyglot Databases

As many organizations undergo the latest modernization cycle, many companies and agencies are turning towards cloud storage as a partial solution to help become a more data-centric group. In the current technical landscape, there are two main patterns to cloud data storage: multimodel and polyglot. Agencies will generally have to choose between the two when planning out their modernized architecture. So what are they, and how do you choose?

The traditional approach is to use polyglot persistence as your database pattern. The polyglot approach involves choosing the best-of-breed datastore for each type of data the organization requires to store. Need to store financial transactions? Use the best relational database you can find. Need to enable quick searching? Adopt ElasticSeach for that use case. Require storing user sessions? Adopt a key-value database. In this way, the company can pick and choose which datastores it needs, along with which technology is the best fit in each area.

This approach has several clear advantages. Each organization can tailor the specific database to their use case. Perhaps Oracle is a better relational database for company A. However, Postgres is the optimal choice for company B. With polyglot persistence, it is encouraged that companies choose the vendor that provides the most excellent capabilities in the specific data storage area.

Polyglot persistence also allows for the compartmentalization between critical functions of an application or organization, creating a modular environment. In this modular environment, performance is optimized within each individual datastore, leading to faster operations.

There are significant risks in the polyglot undertaking, however. While you now have the best option for each data type, the onus of integrating those data stores to work seamlessly is on the company’s technical team. This team will not only have to integrate these separate technologies but will also have to maintain expertise in each technology to support future development. Additionally, the company will bear the burden of paying multiple licensing and maintenance costs, one for each product.

Because of these key drawbacks, many companies are now offering the ability to store multiple types of data behind one storefront. Enter the multimodel database.

A multimodel database is a unified database for different types of data – it contains and manages many different data types and models, all integrated by a single back end. Such databases can store tabular, relational, columnar, document, graph, key-value, and non-relational data and models in one place. The semantics for the database model (across all data stores) is described under a single underlying query language, making retrieving data across data stores much more straightforward than with polyglot persistence. This one-stop-shop makes interacting with an organization’s complex data much simpler.

Unlike with polyglot persistence, the company no longer has to pay multiple licensing costs or maintain a knowledge base in numerous technologies to upkeep their modern system. Additionally, some mutlimodel databases ensure ACID guarantees across all datastores, which is much harder to guarantee in individual databases with polyglot persistence.

There are a few drawbacks of multimodel databases. They are a relatively new technology, so there are a limited number of vendors with little history. This lack of historical experience can be a big red flag for large organizations trying to modernize. Some multimodel offerings may not include a type of datastore that an organization needs, thereby limiting the options for the organization. Additionally, because multimodel databases blend data, the optimization occurs at a higher level, which can be less performant in individual business areas.

So, which is right for your organization? While it is expected that multimodel databases flourish in the upcoming years, each organization needs to start with a full understanding of their data, their use cases, and their access patterns before diving into a major architectural decision such as this. Once the due diligence is completed and the data environment of the organization is well understood, the choice between multimodel database and polyglot persistence should be much easier to approach.