One of the most popular open source databases is PostgreSQL, in 2018 even declared DBMS of the Year. In this blog Martijn Wallet shares the most important advantages of using Supported PostgreSQL such as EDB Postgres Platform as compared to native PostgreSQL.
Opensource increasingly popular
Opensource databases are becoming increasingly popular among organizations who are looking for powerful and cost-effective alternatives to the licensed databases. According to a report by Gartner Research, by 2018 more than seventy percent of the internally developed applications were already using an open source database management system (DBMS).
Native PostgreSQL in a nutshell
PostgreSQL is a relational, open source DBMS that has existed since 1996. It is one of the oldest and most solid open source systems, with an excellent reputation, thanks in part to the effort of the community. This community consists of a wide variety of individuals from many different backgrounds. Suggestions for features and code can be submitted by anyone, but the core team members and source code committers ultimately make the most important decisions for each release. New releases are published annually, updates are provided every three months, and, when necessary, ad hoc security or maintenance updates are published. Users can download the source code for free and build the database binaries themselves. If they prefer not to do so themselves, they can either obtain PostgreSQL for free from a number of packagers who include it in their software distribution - such as Red Hat Enterprise Linux - or from www.postgresql.org or the EnterpriseDB website. The PostgreSQL software license is fairly straightforward and allows use without cost or signed agreements. It also allows modifications and redistribution without the need to return these changes to the community.
Supported PostgreSQL in a nutshell
Supported PostgreSQL such as the EDB PostgresTM platform starts off with native PostgreSQL and adds a range of enterprise-class features and tools for security, performance, high availability, backup and recovery, data migration, integration and management. These critical components are used by thousands of organizations around the world to reliably serve Postgres on a large scale and to minimize risk.
For all those extra services around the native version of PostgreSQL, the user pays so-called subscriptions fees. Although these are disproportionate to the license prices of the Microsofts and Oracles of this world, they are costs that must be taken into account.
Native PostgreSQL vs Supported PostgreSQL
In the supported PostgreSQL distributions, tools are developed, maintained, packaged, distributed, supported and documented by commercial parties such as EDB. These tools, which make the main difference between the use of native PostgreSQL and the supported versions, help organizations with:
- Management
- Monitoring
- Tuning
- High availability
- Disasterrecovery
- Database replication needs
Often, a supported version also offers a wider range of options for database implementation, including:
- Bare metal
- Virtual machines
- Kubernetes
- Private cloud
- Public cloud
- Hybrid cloud
Finally, with the platform you can count on:
- 24x7 technical support
- Training and certification
- Professional consulting
- External DBA services (such as with OptimaData)
Support for developers as well as for DBAs
The supported versions often also offer features that specifically improve productivity for application developers, such as pre-defined reusable feature packs and improved data types. In addition, they often offer special features to make day-to-day database management tasks more productive, such as dynamic metrics, views and automated error detection.
Native PostgreSQL not an option then?
Although it seems like supported version should always be preferred, this is by no means the case, provided the organization has sufficiently qualified PostgreSQL specialists at its disposal. After all, also native PostgreSQL offers support options. Questions can be asked through the PostgreSQL community, and staff has to look for updates, patches and security issues themselves. In addition, answers to FAQ certainly can be found, but often on various blogs and sites. While this approach provides interesting work for the teams, and ultimately for a very mature IT organization, it also entails risks for continuity and data integrity. Nevertheless, these risks can also be solved by engaging a reliable PostgreSQL partner.
Would you like to know more?
As always, every choice has its pros and cons and it depends very much on the organization, which choice is the right one. Feel free to contact us if you would like to discuss in more detail the choice between native and supported PostgreSQL.
More blogs about PostgreSQL: