Skip to content
Announcing BigAnimal: Fully managed PostgreSQL in the Cloud
Contact usDocsPlans

4 Ways Your Cloud Provider's Native PostgreSQL Can Hold Back Application Development

EDB Team10/12/2021
Cloud

When developing a new or migrating an existing application to the cloud, the database plays the same critical, strategic role it does in an on-premises environment. For a developer that has already made the decision to capitalize on PostgreSQL’s robust community, it can seem like an obvious next step to embrace their cloud provider’s native PostgreSQL. 

Yet such an “obvious” decision can result in negative downstream effects if developers don’t fully investigate the limitations of a cloud provider’s PostgreSQL offering. Whether you’ve chosen Amazon Web Services (which has two cloud PostgreSQL offerings - RDS and Aurora), Microsoft Azure, or Google Cloud Platform, here are four things to consider before you finalize your decision. 

 

1. Level of control

One of the most significant challenges for developers to consider when adopting a cloud provider’s PostgreSQL database is how much control of your database, operating system, and software stack that you cede to AWS, Microsoft, and Google. 

Certainly, the advantage to a managed cloud database is manifold. By relying on the cloud providers to automate and manage such administrative tasks as provisioning capacity, installing and maintaining database software, and performing back ups, application developers free up resources to focus on feature development and innovation. 

In the case of cloud providers, however, the abstraction of such administrative tasks can bring with it a parallel abstraction of certain advanced configuration options, such as the ability to choose where your data is located. In some cases, such control is unnecessary—a standard, off-the-shelf application, for example, may not require customized control—but for many developers, the inability to obtain root access to the database or super user access to pg_tables creates constraints, particularly when developing complex applications.

Ultimately, the cloud databases offered by cloud providers require a black box-like blind faith in their PostgreSQL database instead of the ability to control the compute, storage, functionality, and database internals.

 

2. Ease of migration

Application owners migrating from an existing on-premises database to the cloud face different considerations depending on the situation. For those looking to move an existing Postgres-based application to the cloud, the migration is comparably simple, though developers will want to confirm that their specific configuration can be replicated in the cloud. Many cloud databases limit which Postgres versions they support, size and scalability within a region, or the amount of storage or number of instances you can run simultaneously.

For applications that currently run on a non-PostgreSQL database, the migration is obviously more complex. While cloud providers like to tout ease of migration and may provide access to migration tools to simplify the process, the reality is that many of those tools are relatively basic open source tools that provide simple advice and execution processes, but fail to provide meaningful guidance and automation as it relates to application impact. 

This is particularly true of Oracle to cloud PostgreSQL migrations due to the high number of Oracle-specific queries that get built into applications. Without a sophisticated migration tool that can help smooth over some of those migration challenges, application owners may find themselves suddenly in the midst of a complex and costly migration incurring expensive professional services fees to help with application changes. 

 

3. Vendor lock-in and rising, unpredictable costs

One of the biggest considerations in working with a cloud provider’s PostgreSQL database is flexibility if you decide to make a change or support a multi-cloud deployment. Unsurprisingly, all the cloud providers provide dramatic incentive to remain wholly on their platform. In the case of Amazon Aurora, for example, AWS has dramatically modified PostgreSQL, making any future transition much more difficult. 

Moreover, the lack of configuration options as outlined in the previous section can help drive costs up unpredictably given complexity across CPU, memory, storage, backup, data transfer, etc. In some instances, scaling storage down is disallowed, impacting customers’ flexibility and cost control efforts. 

 

4. Open source community engagement

One major benefit of using an open source database such as PostgreSQL is taking advantage of the commitment, responsiveness, and participation from the community. Cloud generalists, however, are typically unable to stay close to the database. They often lag with bug fixes and security updates, are unable to contribute new features that their customers need, and typically cannot keep up to date with the newest version. 

Without a direct line to the open source project, it can be difficult to advocate for a desired feature or modification. 

 

Conclusion

Ultimately, cloud providers are generalists, not dedicated database experts. Given the criticality of the database to an application’s performance and operations, the limitations outlined above need to be carefully considered and managed before moving forward with a cloud provider’s native PostgreSQL offering. 

Want to learn more? See a preview of EDB Cloud!