Most organizations with database needs have explored migrating their database operations to the cloud. Cloud-based database environments offer increased levels of convenience and reliability, making it easy to manage and control database access anytime, anywhere. But not every organization is ready to shift its entire database operations into the cloud. The process may start with a few applications that benefit from specific cloud-based functionality, but for legacy and traditional databases, on-premises solutions remain in use to keep critical business processes running.

The result is a hybrid approach to cloud-based database environments. Hybrid cloud environments rely on both public and private cloud providers for application support – and not necessarily for the same applications. Whether it’s because of an intentional decision by an organization or the result of groups moving workloads into the cloud on an ad hoc basis, varying enterprise database needs means supporting both on-premises databases and a variety of different cloud-based database systems from multiple vendors.

Many hybrid cloud environments arise accidentally when different groups choose whether to deploy a given application on-premises or on cloud platforms based on their own criteria, and an enterprise ends up supporting a diverse set of clouds in addition to their traditional on-premises systems. As many companies are still in the experimental phases of cloud adoption, this can actually have advantages because it gives them experience in many different environments to help inform future choices. In the long run, however, it will likely create a new legacy because applications may take advantage of proprietary features of a particular cloud, making it difficult to move in the future.

Organizations that take a more intentional hybrid database approach make conscious efforts to distribute workloads across clouds, both between public versus private and across various public clouds. This is often done both to match the workload to the cloud that supports it best and to perform arbitrage to find the most cost effective platform on which to run a particular application. Many intentional hybrid approaches embrace containers and container orchestration technology such as Kubernetes, OpenShift and Pivotal Cloud Foundry (PCF) to simplify moving applications between cloud environments.

When taking this intentional approach, one reason an organization may decide to keep a given database on-premises is due to a predictable workload that sees fewer benefits from being run in a public cloud. In the public cloud, organizations have more flexibility to scale up, down and on-demand, without requiring the purchase or configuration of new hardware. However, clouds typically have less control over achieving the absolute best performance and often don’t provide the same availability features, such as traditional failover mechanisms.

Determining whether a database is better suited for a cloud or on-premises solution often comes down to the nature of the workload that database is designed to support. Database workloads generally fall into three broad categories, systems of engagement, systems of analysis and systems of record, whose characteristics can make them more or less appropriate for cloud deployment:

• Systems of engagement, which tend to be web facing and mobile and can carry an unpredictable number of users, can often benefit from a cloud hosting environment that can easily be scaled up or down on demand.

• Systems of analysis or systems of insight also benefit from cloud migrations if they only run occasionally or have high periods of usage, like end-of-quarter reporting.

• Systems of record tend to still benefit from being deployed on-premises because they’ve often been in place for a long time and have high stability. Migrating high-performing, predictable database operations into the cloud simply for the sake of having all operations run in the cloud often is not worth the risk.

Cloud deployment often starts with new applications that are likely to be systems of engagement since they benefit the most from the flexibility of the cloud. These deployments often are initiated by those who wish to move existing applications or build new solutions in cloud because of their own experience, background and risk profile.

It’s worth noting that when deciding which cloud to put a database system into or even whether to put it in a public cloud at all, the database isn’t typically the driving decision — it’s the application. When a developer sets out to build a new application, they will choose the cloud or clouds that offer the best services to develop and deliver that application logic.  The database supporting that application is really just along for the ride and has to be able to fit into that environment successfully. This is one of the key reasons Oracle may find it challenging to encourage the use of their cloud beyond their own applications, even if they provide extremely high qualities of service for running the Oracle database. It’s also a reason why databases that can fit well into any environment have a big advantage in giving application developers the most flexibility in their choice of deployment target.

To truly get the most out of a hybrid database environment, EDB Postgres in the Cloudoffers a powerful solution with an unprecedented amount of control. Running the same Postgres both on-premises and in the cloud, EDB Postgres in the Cloud gives organizations greater control over their database environments with industry-leading flexibility and scalability. EDB’s fully managed DBaaS is one solution, but so are EDB Containers. And some others may simply want to stand up a database server and operate it themselves. It will depend on the use case what approach is best. There is no one-size-fits-all solution to meet complex and changing database needs. The flexibility we offer users is choice.