Don’t panic! A converged database doesn’t mean the return of monolithic databases

There’s this moment when I’m talking to developers, and I show an image of a converged database with the many data types and workloads it handles, and I see some of them tune out. “Not the same old monolithic database,” they seem to be saying to themselves.

“Wait,” I say. “Don’t let that image fool you.” 

Here’s what I mean: A converged database is worlds away from a monolithic database. Yes, it’s multi-model and multi-workload, but it’s also multitenant. And when you put those together, you get an architecture that supports all the latest development methodologies, including microservices, making app dev easier and way more manageable than if you build apps using multiple single-purpose databases.

What makes microservices great is that each application module can be built and deployed in complete isolation from the rest of the application. This method creates greater agility because each service can be developed, upgraded, and deployed independently. It also offers higher availability because if one microservice goes down, the other microservices remain open for business.

For all its advantages, however, microservice architecture comes with a ton of complexity. In fact, I recently saw Uber is moving away from microservices in some instances because testing and maintaining thousands of microservices “is not only hard - it can cause more trouble long-term than it solves in the short-term.”

Oracle’s converged database is designed precisely to solve this complexity problem. “So stick with me for a sec,” I tell my developer audience.

Oracle makes it simpler to deploy microservices with its multitenant architecture by allowing each microservice to store its data in a logically separate data container called a pluggable database. For example, one pluggable database in your application might be a JSON document store, another could be a graph database, another could be for relational data, etc. And all these pluggable databases are combined into a single physical database that you can support holistically.

The several data stores plugged into that one physical database can all be upgraded and backed up together, making it much easier for you to keep the various microservices in synch. And suppose one service does need to move to a different database software version or suddenly has new high availability requirements. In that case, it can be easily unplugged from its current physical database and plugged into another one that meets those requirements without impacting the other services.

Not only that, if the functionality requirements for one of the services changes mid-project due to unforeseen business needs, then there is no need to panic. The technology you need to support the new requirement or use-case is built right into each pluggable converged database. So there is no need to spin up yet another data store.

In short—once I have the developers’ attention—my message is this: Use our converged database to take advantage of whatever data model you want and whatever data types your application needs, and run them as independent microservices. BUT do it in a multitenant architecture. That way, the microservices can easily communicate using data events rather than code events, and they are maintained together, so you get a synchronized view across all those databases. There’s nothing monolithic about that.