EnterpriseDB is about to announce the release of EnterpriseDB Postgres Advanced Server (EPAS) 11, with lots of new and exciting features.
Starting with v11, EnterpriseDB will stop building “1 Click” installers for Linux, and move to native packaging for all supported distributions. EDB released RPMs for RHEL, CentOS and SLES a couple of years ago, and this year we will support native packages on Debian 9 (Stretch) and Ubuntu 18.04 as well.
The PostgreSQL community already provides native packages on a number of platforms, and it is considered the best way to install PostgreSQL on those platforms. EDB is now bringing this enhancement to our products as well.
Installers have been used widely and are very useful to many customers. However, they also come with a number of significant disadvantages on Linux platforms.
Maintenance
Installers are designed to work on a range of supported Linux distributions. This causes significant maintenance problems as well as usability problems. To satisfy dependencies on all supported platforms (for example SSL and LDAP libraries) installers ship with their own libraries, which do not match the ones in the operating system. This can cause compatibility issues (especially if the user is building software that links against libpq for example) and requires the installation to be updated when there are security updates to dependencies as well as when the package itself is updated.
Integration
Whilst the EDB installers are very flexible and do allow various installation modes, they don’t integrate with platform native package management systems such as Yum, DNF or APT. This means that system administrators need to handle updates to the system using two different techniques. It also means the monitoring for available updates must be done twice, once for the operating system and its components, and once for the installer.
While talking about integration, we also have to stress on the fact that the native packages integrate well into Puppet, Chef, Satellite and other management/provisioning tools making it much easier to deploy systems using those and similar technologies.
Deeper integration also offers future advantages as we enhance native packages; for example, using installation directories that follow platform-specific packaging guidelines makes it feasible to create SELinux security policies, and having per-platform builds allows the database server to link with and cooperate with more advanced features of SELinux allowing deep integration with mandatory access controls giving the ability to create multi-level security systems.
Ease of use
Like the RPMs, we tried to use the PostgreSQL community packaging infrastructure as much as possible in the EDB Debian/Ubuntu packages. If you are already familiar with the Debian/Ubuntu community packaging, the tools like "pg_createcluster", "pg_lsclusters"", etc are available, with epas_ prefix instead of pg_ prefix. This will help users to get used to EDB packaging quickly and easily.
Ease of update
Yum/DNF/APT update is already the way to update the packages in the operating system. Native EPAS packages help you to get rid of extra update procedures, so upgrading EPAS is easier than ever.
Tools
EDB's own BART and EFM were already packaged as RPMS in the past. Our Debian/Ubuntu users were not able to use them on their platforms. In this release, we also start distributing these tools as native packages, along with our other tools like PEM. This will help our customers to deploy these tools on more platforms in a consistent way.
Performance
Because installers were designed to work on multiple Linux distributions, there was always a performance hit due to the fact that the packages had to be built for “the lowest common denominator”. That essentially means building against the oldest libc library, using older compiler versions resulting in loss of any possible performance gains found in newer libraries and compilers.
Customization
One advantage of installers is being able to specify the location of both binaries and the data directory during startup. Even though it is technically possible, per packaging guidelines the native packages are not relocatable; this means, users cannot change the binary/library/etc. installation path. Symlinks are an alternative to solve this issue. On the other hand, data directories can always be defined during cluster initialization phase, so users will not have issues during this transition.
Community Packages
There are hundreds of thousands of users of the EDB PostgreSQL installers, the vast majority of which are Windows and Mac users. Whilst we’re continuing to provide the installers for those users, as of version 11.0 of PostgreSQL we are no longer providing installers for Linux. Users are encouraged to use the platform native packages for their operating system which can be found on the appropriate download page under https://www.postgresql.org/download/.
We will continue to support the Linux installers for PostgreSQL v10 and below, until their published end of life dates.
Conclusion
Whilst the move to native packages on Linux will cause changes for users, there are clear benefits in having EDB Postgres applications that are packaged following the standards and guidelines set by the vendors of the operating systems that we support, making the transition highly beneficial for both us as the vendor and our users in the long term.