Postgresql 18 Linux (all flavors) - with installation, create new instance/main database

Overview

This thread is not a technical design discussion of PostgreSQL internals but rather a short policy/packaging discussion triggered by a user feature request. The OP proposes that installing PostgreSQL 18 on Linux should automatically run initdb to produce a ready-to-use instance. The proposal is unanimously rejected by senior community members on well-established Unix packaging principles. Despite its brevity, the thread is notable because it articulates the project's long-standing stance on the separation between software installation and service provisioning.

The Core Proposal

The original poster (Andre Verwijs, posting twice from two different addresses) suggests that the Linux install flow should, as a final step, execute:

sudo -u postgres /usr/pgsql-18/bin/pg_ctl -D /var/lib/pgsql/18/data/ initdb

The implicit model is a Windows-style "installer" experience: after make install / package install, the server is immediately usable with a default cluster at a conventional data directory path (/var/lib/pgsql/18/data/, which is the PGDG RPM convention, not the Debian/Ubuntu convention /var/lib/postgresql/<version>/main/). That path-convention mismatch alone illustrates why this cannot be a universal upstream behavior — the data directory layout is a packager decision, not an upstream one.

Why the Proposal Is Rejected

Three distinct but reinforcing arguments emerge:

1. Scope of make install (David G. Johnston)

Johnston draws the line at the build system boundary: make install / ninja install is responsible only for placing binaries, libraries, headers, and shared data files into the configured prefix. Running initdb would:

• Require a writable data directory path chosen at install time (violating relocatable installs).
• Require a postgres OS user to exist (a packaging concern, not a build concern).
• Side-effect state outside the install prefix, breaking DESTDIR-style staged installs used by every distro packager.
• Conflate the roles of upstream source and downstream packager.

This is the architecturally cleanest objection: the build system has no business provisioning runtime state.

2. Legitimate reasons to install without a cluster (Isaac Morland, Andrew Dunstan)

Morland points out — and Dunstan strongly agrees ("+1 It's annoyed me many times") — that many valid deployments install PostgreSQL binaries without wanting an auto-created cluster:

• Client-only installs (libpq, psql, pg_dump) on application servers.
• Hosts that will join an existing replication topology via pg_basebackup and therefore must not have a pre-initialized data directory.
• Hosts managed by configuration management (Ansible, Puppet, Chef) or orchestration (Patroni, repmgr, Kubernetes operators) where cluster bootstrap is controlled externally with specific locale, checksum, WAL-segment-size, and authentication settings.
• CI/test environments that create many ephemeral clusters via pg_createcluster or initdb with custom parameters.

Morland notes Ubuntu's default auto-provisioning is actively disliked and must be suppressed via a preseed/config file — evidence that even a packager doing this is considered a misfeature by experienced DBAs.

3. Distribution policy precedent (Tom Lane)

Tom Lane — the senior-most committer in the thread — invokes Red Hat's long-standing packaging policy: installing a package must not start or configure a service. The rationale is operational safety:

"you should be able to select fairly large package sets at system install time and not worry about half-configured servers starting up on you."

Lane identifies the two conditions under which Red Hat historically made exceptions:

• (a) The service is essential to system functionality (e.g., systemd, dbus, sshd in some configurations).
• (b) The default configuration is both secure and widely useful as-is.

PostgreSQL satisfies neither. A default initdb produces a cluster with trust authentication on local sockets, default locale/encoding inherited from the installer's environment (often wrong for production), no tuned shared_buffers, no replication configuration, and no checksums (the --data-checksums default only flipped in PG18). Auto-provisioning such a cluster would be a security and operability footgun.

Key Technical Insights

Cluster bootstrap is irreversibly parameterized. initdb choices — locale, encoding, collation provider (libc vs ICU), data checksums, WAL segment size, default tablespace location, superuser name — are either impossible or very expensive to change after the fact. Auto-running initdb with defaults locks users into decisions they did not make consciously. This is categorically different from, say, auto-starting nginx with a default config that can be edited and reloaded.

The postgres OS user lifecycle is a packaging concern. Creating the unprivileged runtime user, setting its $PGDATA, managing its home directory and .bash_profile/PATH, and arranging for systemd unit files all belong to the distribution package (postgresql-server RPM, postgresql-<version> deb). Upstream has no portable way to do this.

Multi-version coexistence. Debian/Ubuntu's postgresql-common infrastructure deliberately supports multiple major versions side-by-side via pg_lsclusters, pg_createcluster, pg_upgradecluster. Auto-creating a cluster on install would conflict with this design, which is one reason Morland complains about Ubuntu's default behavior even within that well-engineered framework.

Who Carries Weight

• Tom Lane — core committer since the project's inception, former Red Hat employee, authoritative on both PostgreSQL internals and Red Hat packaging policy. His invocation of the Red Hat rule effectively closes the discussion.
• Andrew Dunstan — core committer, build-farm maintainer, MSVC/Windows build expert. His "+1" from operational annoyance carries practical weight.
• David G. Johnston — major contributor, documentation authority, very active on -hackers and -general. Frames the architectural boundary argument.
• Isaac Morland — frequent -hackers participant with operational/DBA perspective.
• Andre Verwijs (OP) — appears to be an end user, not a regular contributor.

The rejection is unanimous and comes from three committers/senior contributors, so there is no controversy to resolve.

Outcome

No patch, no follow-up, no TODO item. The proposal is declined on policy grounds. The thread serves as a useful reference for the project's position that PostgreSQL installation ≠ PostgreSQL provisioning, and that cluster creation is intentionally a deliberate, user-driven act.