Several years ago, EnterpriseDB (EDB) decided to deprecate the one-click installers for Linux in favor of native packages. EDB still provides and updates one-click installers for Linux for EDB Postgres 9.6 and earlier. EDB also provides one-click installers for EDB Postgres on Windows and for PostgreSQL on OSX. This blog describes how that decision helped our customers make their Postgres installation more manageable, more secure, and more performant.
Life Before Native Packaging
In “the old days” Postgres users had two options to install Postgres on Linux: compile your own or use a one-click installer, such as the ones provided by EDB.
The “compile your own” approach required the installation of a lot of additional software, such as compilers, required a lot of know-how that was often not available in a DBA team, it made maintenance much more involved as every update required a recompilation, and added significant security concerns.
The one-click installers alleviated quite a few of those concerns, but they introduced two other issues: one-click installers use common-denominator libraries across different Linux flavors - those libraries are not necessarily optimized for a certain flavor and version of Linux, and the installer ‘installs’ all libraries necessary to operate the database into the directory of the database. This means that multiple versions of the libraries, including some with known security vulnerabilities, could co-exist on the same server. This also meant that the database installation had to be updated every time one of the included libraries was updated -- even if a version of that library already existed (and had been updated) at the OS level.
One-click installers were an improvement over the ‘compile your own’ approach, but they were not optimal for performance, manageability, or security.
What Is Native Packaging?
A native package bundles binaries and libraries that are unavailable in the operating system, and documentation for easy installation. Please note: native packages use the available OS libraries where possible - they do not install their own version. The binaries and the libraries are precompiled for that specific operating system - they are not a lowest common denominator across multiple platforms. This removes the duplication of libraries, optimizes performance for the OS and the Postgres version, and allows database software installation to take advantage of new library versions when the underlying OS software gets updated.
Benefits of Native Packaging
Native packages address the key weaknesses of one-click installers: duplication of libraries and ‘lowest common denominator’ versions of those libraries. Native packages greatly improve performance and manageability.
Native packages integrate well with OS package management tools, such as YUM (for RedHat Enterprise Linux (RHEL), CentOS, Fedora), APT (Debian and Ubuntu) or ZYPPER (SUSE Enterprise Linux), and work very well with software deployment and configuration technologies such as Ansible, Chef, Puppet or Salt, making deployment at scale in the enterprise much easier.
On RHEL, they also make it easier to work with SELinux.
EDB Postgres and Community PostgreSQL Native Package Repositories
EDB and the PostgreSQL Community offer native package repositories for a wide variety of operating systems.
PostgreSQL Community:
EnterpriseDB:
As of today, the vast majority of EDB’s customers using Linux prefer native packages. The advantages in manageability and performance are so significant that the percentage of customers using one-click installers has declined significantly over the last two years.
This blog is co-authored by Marc Linster and Devrim Gündüz. Devrim Gündüzm Principal Engineer, is actively involved in maintaining the PostgreSQL Community YUM and ZIPP repositories.
Want to dive deeper into why you should use native packages to install PostgreSQL on Linux? Watch our on-demand webinar!