Skip to content
EDB
Upcoming Webinar: What’s New in PostgreSQL15 • Dec 7 • Register Now

Blog

Options for Moving Your Database to the Cloud

Marc Linster10/18/2022
PostgreSQLCloud

As enterprises plan their cloud migration , they look for technologies that can help them compete and react in today’s fast-paced, unpredictable world. This means solutions that provide agility, scalability, high performance and security while also minimizing the time spent on maintenance, provisioning, and administrative overhead. Choosing the right cloud migration strategy, and along with it, the right database, is particularly critical for overall success. 

Postgres databases have become a top choice for organizations looking to build and run modern applications. Why? Because Postgres is known to be a highly capable database that supports complex and demanding applications, is loved by developers, and runs everywhere.

Let’s look at why enterprises are considering cloud migrations and what choices they have for their database strategy.

 

Key drivers for moving from on-premises to the cloud

Enterprises are looking to the cloud to get more freedom, flexibility, and greater agility from their technology infrastructure so that they can innovate faster. The automation and abstraction cloud services provide enterprises allow them to be more flexible, responsive, and focused on activities that drive business value, instead of activities that are routine and overhead. We’re far enough along in the existence of cloud computing to know that on-premises technology can limit the ability to innovate quickly. 

Migration map

A move to the cloud helps with agility because we can seperate the work to innovate, that is write new code, new queries and new business procedures, from the work to run and maintain the infrastructure. In an on-prem scenario, when the business needs a new database, the enterprise team has to procure hardware, rack and stack it, install the OS, and integrate everything into the corporate infrastructure before turning it over to the application team, who will focus on the actual business value add. That’s a process that can easily take weeks. In a cloud environment, the new database can be provisioned in 20 minutes!

Similar issues limit the ability to be innovative. Cloud database platforms offer a wide range of services which allow for experimentation and use of specialty technology for single projects. This is essential for prototyping new ideas. On-premises deployments commonly require a bigger commitment to technology in terms of licenses, hardware, and operational skills. This makes it much harder for enterprises to quickly try something new. And once they try something new on prem, they tend to be committed to long-term licenses - which makes ‘fail fast’ impossible.

Globalization is another driver for the move to the cloud. Data needs to be stored close to the user for performance and compliance reasons. On-premises models for these needs are prohibitively costly and are too complex to meet the rigorous demands of global internal teams, suppliers, and customers.

Databases are historically resource-intensive to keep highly available and maintained. On-premises, they require whole teams to maintain, update, and provision the database, perform backups, plan for disaster scenarios, and implement recovery. These overhead activities are prime targets to delegate to an “as a service” deployment.

 

“As a service” options for cloud databases

There are three options to take a database to the cloud: Virtual machines, containers, or Database-as-a-Service (DBaaS).

A recent survey on LinkedIn showed that DBaaS is the more popular option for moving to the cloud, but virtual machines on Infrastructure-as-a-Service (IaaS) and containers with Kubernetes (sometimes abbreviated K8s) also have significant success in the market:

Q: How are you moving your databases to the cloud?

Virtual Machines on IaaS

10%

Kubernetes and Containers

35%

Database-as-a-Service

55%

DBaaS is the most popular—according to Gartner, cloud databases now account for 49% of all database spend—and with good reason. Here is a table that outlines how each one of these meets the “as a Service” requirements.

 

VM on Iaas

Kubernetes with containers

Database-as-a-Service (DBaaS)

On Demand

No (Infrastructure as Code will help)

Improved (Level III+ K8s operator automates failover, upgrades, backup/recovery)

Yes

Broad Network Access

Yes

Yes

Yes

Resource Pooling

No

Yes

Yes

Rapid Elasticity

No (Infrastructure as Code will help)

Improved (Level V K8s operator will address database elasticity)

Yes

Measured Service

No (IaaS resource consumption only)

Improved (Level IV K8s operator will address database metering)

Yes

Only DBaaS actually meets the requirements of a cloud service. While Kubernetes represents a definite improvement over Virtual Machines in terms of the key “as a Service” requirements, it still lacks the central control plane that is key to implementing the shared responsibility model.

However, there are other trade offs to consider:

 

Advantages

Considerations

VM IaaS

  • Full control including when to apply upgrades
  • Ultimate configurability and tuning at the database and OS level
  • Any extensions and versions
  • Highest performance and lowest 3rd party cost
  • Need infrastructure DBAs
  • Need 24x7 monitoring
    You are responsible for configuration and day-to-day operation
  • Minimal automation

Kubernetes on Containers

  • Operates many lifecycle tasks: install, failover, backup/recovery, upgrades, etc.
  • Users decide when to apply upgrades
  • Works best when application is containerized and K8s is used for the whole stack
  • Limited configuration options 
  • Need K8s expertise and acceptance of the “K8s way” of doing things
  • Need 24x7 monitoring

Managed Database Service

  • SRE team monitors and operates
  • SRE applies upgrades
  • You focus on innovation, they keep the lights on
  • Relinquish significant control
  • No OS tuning
  • Limited database extensions
  • The user has limited control over upgrades

 

What are the advantages and disadvantages of DBaaS?

In a DBaaS, the cloud database operator (CDO) assumes key responsibilities: managing the software, the hardware, and the network, while assuming responsibility for the service availability. That represents the biggest advantage - the DBaaS customer doesn’t have to worry about those tasks. But the biggest consideration is that you, the customer, are completely dependent on the CDO to discharge these tasks well and in a timely manner that does not interrupt the database service. You also may not dictate when your CDO decides to update, or not, your database. For example, one of the leading DBaaS for Postgres was lagging behind on providing the latest version of open source Postgres by over two years.

Another challenge arises from the segregation of duties. As the CDO is responsible for maintenance of the operating system and the installation of the database software, the user will not be granted operating level access, which means that certain configuration parameters, logs, and software add-ons will not be accessible for tuning and diagnostics. 

But even with these few drawbacks, more and more enterprises want their IT resources focused on innovation and business-oriented value add, such as data stewardship and analytics, and are more than happy to leave the behind-the-scenes grunt work that keeps the lights on to a cloud database provider.

EDB BigAnimal overcomes these drawbacks

Compared to Postgres offerings from the public cloud providers, our EDB BigAnimal fully managed service comes with some notable advantages. 

The first is that we offer a choice of Postgres. You can provision either open-source PostgreSQL or EDB Postgres Advanced Server, which includes additional enterprise features not found in the open source version - things like compatibility with Oracle. And we support the latest version of Postgres.

A second major advantage is the Postgres experience of our team. With more than 300 Postgres experts on staff and over 40 contributors to Postgres 14 (and the soon to be available Postgres 15), you can rest assured that you’re getting the most experienced Postgres support available in the industry.

Another notable difference with BigAnimal is the ability to not only gradually shift workloads from on-premises to the cloud—there’s no price penalty for doing so – you can also freely select which cloud provider you use. Want AWS for one project and Azure for another? With BigAnimal, that’s no problem. (And, we also offer Cloud native Postgres on Kubernetes if that’s your preference.)

 

If you’re ready to learn more about how EDB BigAnimal works, check out our free test drive.

Marc Linster, Ph.D., is EDB’s Chief Technology Officer. Marc is committed to EDB being an accelerator to providing architectural “know how” to help customers take advantage of Postgres without significant risk and cost. Marc believes that although new customer adoption of open source is easier than ...