How Debian Packages MariaDB and PostgreSQL

This article explores how the Debian operating system packages, configures, and maintains relational database management systems, focusing specifically on MariaDB and PostgreSQL. It covers the distribution's packaging policies, versioning strategies, maintenance automations, and architectural distinctions between engines—such as multi-version cluster management in PostgreSQL and unified configuration defaults in MariaDB. Readers will gain an understanding of how Debian provides long-term stability, automated upgrades, and secure runtime environments for critical database services.

Debian Packaging Philosophy for Databases

Debian applies rigorous packaging standards defined by the Debian Policy Manual and the Debian Free Software Guidelines (DFSG). For database software, packaging involves unbundling third-party libraries contained in upstream source archives and linking against shared system libraries instead. This minimizes duplication across the system and ensures that security patches to libraries like OpenSSL, zlib, or PCRE immediately apply to running database engines.

Debian divides database software into modular packages:

  • Client packages (e.g., postgresql-client, mariadb-client) containing command-line interfaces, basic administrative tools, and client-side manual pages.
  • Server packages (e.g., postgresql-15, mariadb-server) containing the main daemons, storage engines, and initial cluster creation scripts.
  • Common and configuration packages (e.g., postgresql-common, mariadb-common) containing cross-version tooling, configuration file layouts, and base system integration scripts.

PostgreSQL Architecture: Multi-Version and Cluster Management

PostgreSQL packaging in Debian is uniquely structured around the postgresql-common framework. Unlike most standard Linux distributions that permit only one active version of PostgreSQL, Debian allows concurrent installations of multiple PostgreSQL major versions and multiple instances (clusters) per version.

Key components of Debian's PostgreSQL maintenance include:

  1. Wrapper Scripts (pg_wrapper): Binaries such as psql, pg_dump, and createdb in /usr/bin/ are symlinks to pg_wrapper. This tool automatically inspects the environment, user configuration (~/.pg_wrapper), and active local clusters to route commands to the appropriate PostgreSQL binary version.
  2. Cluster Abstraction (pg_createcluster): Debian defines a "cluster" as a distinct database catalog collection running under its own port, UNIX domain socket, and data directory (/var/lib/postgresql/<version>/<cluster_name>). Administrators manage instances using tools like pg_createcluster, pg_dropcluster, and pg_ctlcluster.
  3. Configuration Structure: Configuration files are separated from database storage. Files like postgresql.conf and pg_hba.conf reside in /etc/postgresql/<version>/<cluster_name>/, ensuring configuration persistence and integration with Debian's standard /etc backup workflows.
  4. Automated Upgrades (pg_upgradecluster): When upgrading across Debian releases that introduce a newer PostgreSQL major version, Debian provides pg_upgradecluster. This utility uses either pg_dump or PostgreSQL's native pg_upgrade engine to migrate data from the old version cluster to a newly instantiated target cluster with minimal downtime.

MariaDB Architecture: Default Engine and System Integration

Since the release of Debian 9 ("Stretch"), Debian has used MariaDB as its default implementation of the MySQL relational database interface.

Debian's management of MariaDB focuses on standardization and security:

  1. Metapackages and Alternatives: Debian uses virtual metapackages—default-mysql-server and default-mysql-client—which depend directly on current MariaDB packages. This allows other Debian packages needing an SQL backend to declare generic dependencies without binding explicitly to a specific upstream fork.
  2. Socket Authentication: Modern Debian installations configure MariaDB to use the unix_socket authentication plugin for the local root user by default. This eliminates the historical practice of generating random administrative passwords stored in plain-text files (such as /etc/mysql/debian.cnf), allowing administrative access solely to users with root or sudo privileges on the host system.
  3. Modular Configuration Hierarchy: MariaDB configuration files are organized under /etc/mysql/. Configuration directives are broken down into drop-in directories, such as /etc/mysql/mariadb.conf.d/ and /etc/mysql/conf.d/. Debian packages place engine-specific defaults in these directories, while allowing local administrators to override settings via lexically ordered configuration snippets (e.g., 50-server.cnf).

Maintenance, Security, and Systemd Lifecycle

Debian maintains database servers throughout the stable release lifecycle using defined operational safeguards:

  • Security Updates: Debian's Security Team backports critical vulnerability fixes directly to the version bundled with the stable distribution, preserving binary compatibility and preventing unexpected breaking changes from upstream point releases.
  • Process Management via Systemd: Both engines are managed through customized systemd unit files. PostgreSQL leverages template unit files (postgresql@<version>-<cluster>.service) generated dynamically by the cluster framework, while MariaDB runs under a unified mariadb.service unit configured with system-level hardening (e.g., ProtectSystem=full, PrivateDevices=true).
  • Debian Maintenance Scripts: Pre-installation (preinst), post-installation (postinst), and pre-removal (prerm) scripts automate tasks such as creating system user accounts (postgres and mysql), initializing empty databases via initdb or mariadb-install-db, managing log rotation via logrotate, and triggering necessary catalog upgrade routines on package update.