Cloud Database Options: Which Type is Right For You?

Cloud Database Options: Which Type is Right For You?

This is part of Solutions Review’s Premium Content Series, a collection of contributed columns written by industry experts in maturing software categories. In this submission, Datometry Founder and CEO Mike Waas offers organizations three key types of cloud database options to consider during solution evaluation.

SR Premium ContentGartner just revealed that the three hyperscalers are now the largest database vendors. Arguably, no other enterprise software has spawned such an extensive industry. What is even more curious, after over half a century of commercial databases, new database companies keep popping up with impressive regularity, and there is no indication that this market will converge or consolidate any time soon.

While IT leaders globally are currently scrambling to move their organizations to the cloud, database assets are notably still lagging the overall trend for several reasons: committing to a database strategy comes with all sorts of difficulties, technical and otherwise. In addition, they have to navigate company policies and politics, and overcome practical and financial objections.

So, how are IT leaders to make a decision about what cloud database to adopt? Let’s look at a simple but highly effective taxonomy of these systems that breaks down their differences and highlights what kind of database is most suitable for a given situation.

In-Cloud Database: The Quick Fix

We call databases that are deployed in the cloud as a stand-alone software in-cloud database. Think of it as a VM image licensed off a cloud marketplace. An in-cloud system is the same make and model as the on-premises system it replaces and therefore has the exact same functionality. This form factor is a pure IaaS play: the only cloud facility they use is that of managed infrastructure.

In-cloud is a great option when moving out of the data center is the highest priority, especially if that move has to happen in a hurry. Because the new database is the same as the old one, the cost of moving applications between them is relatively low with moderate risk to disrupt the business.

However, moving to an in-cloud database is effectively just a hardware upgrade. There are no other benefits the organization could tap into; no increased scalability, no improved fault tolerance, and no uptick in performance. Worse, the operational cost remains almost the same as the system requires the same maintenance by the organization’s own DBAs.

Cloud-Native: Flexibility at a Premium

Cloud-native databases are developed solely for the cloud, as the name suggests. Cloud advocates have long evangelized the idea that something written directly for a cloud environment is somehow better than adopting existing technology. There is some truth to it when it comes to applications with low complexity. However, it doesn’t seem to apply to databases in the same way since much of their complexity is quite independent of any cloud integration.

The big selling point of cloud-native databases is their ability to run on any cloud. Especially after a painful and costly migration from an on-premises database to a cloud database, customers may feel strongly about avoiding new vendor lock-in. In reality, the vendor lock-in of a database vendor is probably more to worry about than that of the new cloud provider.

The big drawback of cloud-native databases, however, is their price. A cloud-native database vendor passes on the cloud infrastructure cost to its customers and then, on top of that, charges a premium. Vendors often justify that premium with their ability and flexibility to run on different clouds. While often cheaper than its in-cloud sibling, cloud-native databases are considerably more expensive than platform-native solutions (see below).

Platform-Native: The Economy Class

This brings us to the platform-native databases offered by the cloud providers themselves. They deeply integrate directly with other systems and applications on a given cloud. As part of the core offerings on that cloud, they form the backbone of the enterprise architecture. Their enormous data gravity pulls applications onto that same cloud down the road, further increasing the value of these systems to both customers and vendors.

Platform-native systems are particularly cost-effective. Because cloud providers own the entire stack, they can combine license and infrastructure cost in creative ways. They don’t have to pass on the infrastructure cost like the cloud-natives. They might even use the platform-native offering as loss leader. But it doesn’t end there. These databases integrate deeply with other platform-specific offerings, including vertically integrated business applications, to create a unique value stack.

On the downside, platform-native databases exist only on one specific cloud, and cloud providers are eager to create an environment that makes it unnecessary for enterprises to look for outside providers. Notably, Google offers a version of Google BigQuery on its competitors’ clouds, which may well start a trend that blends platform-native with cloud-native databases.

How Do IT Leaders Choose?

Selecting a cloud database is a significant part of any enterprise’s cloud strategy and a decision IT leaders must not take lightly. While most enterprises already have a certain footprint in multiple clouds, many enterprises are still struggling with the decision of where to house their core data processing.

We have seen the above taxonomy work well for IT leaders when it comes to tackling this subject and summarize it this way: In-cloud databases are a great choice for small databases or when the time to move is the highest priority. Cloud-native databases can be the right choice when an overall cloud strategy is not yet defined but transferring of significant data assets cannot wait. However, once IT leadership agrees on a comprehensive cloud strategy, platform-native databases might well be the best choice.

Mike Waas
Follow Mike