Would Beyoncé still be Beyoncé if she couldn’t sing? She would of course technically be the same person, but think of how different her life would be based on whatever career choice her other skills might define. The same is true for Postgres. If you take away its most powerful and unique capabilities, does it become something different?
Postgres is known as the most flexible and extensible DBMS. That was Michael Stonebraker’s original vision when he created the object relational architecture for Postgres back in the late ‘80’s. It is also why so many other solutions like Amazon Redshift and Pivotal’s Greenplum are based upon Postgres, and why it is the ideal technology for extensions such as PostGIS and Foreign Data Wrappers. This architecture is also why the database is so configurable, and able to satisfy the needs of such a wide range of workloads.
Enterprise-ready Postgres tools for high availability, monitoring, and disaster recovery. Download Now.
Amazon RDS and Aurora are admittedly forks of the core PostgreSQL code base. They have to be in order to add the cloud native capabilities they promote. And the ease of deployment of Amazon RDS and the elasticity of Aurora are great additions to core capabilities of Postgres. But what are the trade-offs for these benefits and how do they affect other Postgres capabilities?
Amazon DBaaS offers the same vanilla Postgres configurations for everyone. It simply must be this way in order for Amazon to operate AWS economically at their incredible scale. But the trade-off for this is users (DBAs and Developers) are limited in the configurations and tuning they can perform on the database to optimize performance, storage and availability requirements. It also means rigidity in timing of patches and upgrades. You simply get whatever Amazon is offering when they choose to offer it. And, since Amazon Postgres DBaaS offerings are forks of PostgreSQL, many common extensions are not available.
Many would say this robs Postgres of its very essence. The database built for adaptability and extensibility constrained to one size fits all. At the very least it limits the range of workloads and use cases that would otherwise be possible with a fully accessible core PostgreSQL implementation. One example of this would be migrating Oracle applications onto PostgreSQL for cloud migrations. Postgres is particularly well suited for running Oracle applications because it can be configured and tuned to handle these heavier workloads. But if you can’t tune the Postgres engine to optimize this use case or take advantage of extensions that enhance compatibility, you may be left with a failed migration.
The capabilities that Amazon has added to Postgres with their DBaaS options make it very appealing to developers in particular. Fast, easy deployments without the need for operational IT support. But this also creates rigidity and strips away the flexibility and extensibility that makes Postgres so capable and that DBAs and operations personnel need to do their jobs.
McDonald’s created the fast food industry by standardizing and automating the production of hamburgers. Faster, cheaper food without all the fuss of a sit-down restaurant. And while the predictability of the burger always coming out the same way is comforting, the burgers just aren’t the same as a made-to-order burger in a real restaurant. Which you prefer is usually more a matter of taste, time and suitability for the occasion.
A similar argument can be made for Amazon RDS and Amazon Aurora for Postgres. They offer value and simplicity, but at the cost of significantly limiting the flexibility that makes Postgres what it is. Organizations can also achieve many of the same cost and infrastructure flexibility benefits by deploying core PostgreSQL on Amazon EC2, but without the trade-offs in performance and configuration flexibility required from the AWS DBaaS versions.
This more balanced approach also allows for usage of other Postgres options such as EDB Postgres™ Advanced Server which offers Oracle compatibility and enhanced security features. And EDB Postgres Ark™, which provides a DBaaS framework with the same ease of deployment and elasticity as Amazon Postgres DBaaS, but without the trade-offs in performance, configurability and control. Plus, by including a vendor like EDB as part of your Postgres strategy you can get full database 24x7 support from Postgres experts, Postgres training and a full offering of professional services like Remote DBA and migration assistance for all your Postgres deployments, whether on AWS, Google, Azure, OpenStack or on-premises.
So, the important question is not which version of Postgres is the real or even best one, but rather understanding the benefits and limitations of each Postgres option in order to forge a comprehensive Postgres strategy that best meets all your business goals and objectives. EDB Postgres has the experience and expertise to help you determine your optimal AWS configurations and tuning, assist with implementing your migration, and then provide the long term support and services needed for your success.
Fast food is good, but is usually best consumed as part of a healthier balanced diet that includes the variety, flavor and service of a sit-down restaurant too!
Keith Alsheimer is Chief Marketing Officer at EnterpriseDB.