Building on Multi-Model Databases

Chapter 7. Multi-Model Database Integration Patterns

We’ve taken a close look at the capabilities a multi-model database can bring us in providing agility in data management, securely, and at scale. After people begin to see the benefits of a multi-model database as it relates to their particular data integration challenge, the next often-asked question is, where does a multi-model database fit in my architecture?

The answer is, it depends. We say that jokingly, but with some truth. There’s often a notion that a multi-model database, or any new database being introduced into an environment, will come in to replace some or all existing systems and perhaps do the job of existing systems, either better or with improved performance. Although this can happen, and system replacement might be a goal of IT or the business, when introducing a multi-model database into your architecture, this often just isn’t the case. What happens most often is rationalization and improvement of an enterprise’s integration strategy as a whole, as opposed to incrementally improving a single system.

Other systems exist for very good reasons. The problem with those systems is that they are silos. Given time, and data integration, a multi-model database can replace some existing systems, but that’s not how data integration in these environments begins. More likely, the technologies disrupted by a multi-model database will be those supporting data movement, extract, transform, and load (ETL), system-to-system ...