PostgreSQL auf Ubuntu 24.04 installieren

Worauf das lief und was diese Seite nicht behandelt

Wir haben jeden Befehl auf dieser Seite auf einer frischen virtuellen Maschine bei einem Cloud-Anbieter ausgeführt. Gestartet wurde sie aus Ubuntus offiziellem Server-Image für 24.04, und vorher war darauf nichts installiert oder geändert. Ein Skript hat die Befehle ausgeführt und alles festgehalten, was die Maschine ausgab. Ein Block mit der Aufschrift „Ausgabe“ zeigt, was der Befehl darüber ausgegeben hat, oder die Zeilen davon, auf die es ankommt. Eine Zeile steht immer ganz da, nur Zeilen aus dem Protokoll des Servers zeigen wir ohne die Uhrzeit und die Prozessnummer, mit denen sie beginnen. Die Maschine lief mit englischer Sprache; die Ausgaben auf dieser Seite sind deshalb englisch. Auf einem Ubuntu mit deutscher Sprache können Meldungen und Fragen anders lauten als hier. Das haben wir nicht ausprobiert. Über sich selbst hat die Maschine Folgendes ausgegeben.

date -u +%Y-%m-%d
lsb_release -a
nproc
free -m

2026-10-05

Distributor ID:	Ubuntu
Description:	Ubuntu 24.04.5 LTS
Release:	24.04
Codename:	noble

2

               total        used        free      shared  buff/cache   available
Mem:            3908         457        3265           0         403        3450

Das ist eine Maschine an einem Tag. Du bekommst das PostgreSQL, das an deinem Installationstag in Ubuntus Archiv liegt, deshalb können die Versionsnummern unten bei dir andere sein. Auch sonst wird bei dir einiges anders aussehen. Der Benutzer des Images heißt ubuntu und darf sudo ohne Passwort verwenden. Wo unten in einer Meldung ubuntu steht, steht bei dir also der Name deines eigenen Benutzers. Die Adresse von Ubuntus Archiv in den ersten Zeilen von apt hängt davon ab, wo deine Maschine steht, und diese Zeilen haben wir weggelassen.

Ein Skript hat kein Terminal, und manche Befehle brauchen eins: die Eingabeaufforderung von psql, ein Passwort, eine Ja-Nein-Frage, bevor etwas entfernt wird. An diesen Stellen hat das Skript den Befehl in einem Pseudo-Terminal ausgeführt und die Antworten eingetippt, und der Ausgabe-Block zeigt sie so, wie das Terminal sie wiedergegeben hat. Außerdem hat das Skript jeden Befehl in einer eigenen Shell ausgeführt, während dein Terminal eine Shell für alle ist.

Diese Seite behandelt nicht, wie du die Datenbank von einer anderen Maschine aus erreichst (die Listen-Adresse, die Firewall, TLS), und auch keine Backups und kein Tuning. Wenn du mit ihr durch bist, antwortet PostgreSQL nur auf dieser Maschine.

1. PostgreSQL installieren

Ubuntus Paket postgresql ist kein eigenes PostgreSQL. Es verweist auf das PostgreSQL, das dieses Ubuntu-Release mitliefert, hier 16. Sobald apt frische Paketlisten hat, siehst du, welche Version das ist, noch bevor du etwas installierst.

sudo apt update
apt-cache policy postgresql

postgresql:
  Installed: (none)
  Candidate: 16+257build1.1

Der Kandidat („Candidate“) ist die Version, die der nächste Befehl installiert.

sudo apt install -y postgresql

apt gibt bei der Arbeit sehr viel aus. Zwei Stellen lohnen einen Blick, die Liste der Pakete, die es hinzufügt, und die Zeile, mit der es den Datenbank-Cluster anlegt.

The following NEW packages will be installed:
  libcommon-sense-perl libjson-perl libjson-xs-perl libllvm17t64 libpq5
  libtypes-serialiser-perl postgresql postgresql-16 postgresql-client-16
  postgresql-client-common postgresql-common ssl-cert

Creating new PostgreSQL cluster 16/main ...
/usr/lib/postgresql/16/bin/initdb -D /var/lib/postgresql/16/main --auth-local peer --auth-host scram-sha-256 --no-instructions

Die Optionen --auth-local peer --auth-host scram-sha-256 in dieser letzten Zeile sind der Ursprung des Fehlers aus Abschnitt 4. Die Paketliste kommt in Abschnitt 9 wieder, denn genau diese Pakete müssen beim Entfernen wieder weg.

2. Prüfen, was du bekommen hast

Der Kandidat oben war die Versionsnummer eines Pakets. psql meldet seine eigene Version, und das ist das PostgreSQL-Release, mit dem es gekommen ist.

psql --version

psql (PostgreSQL) 16.15 (Ubuntu 16.15-0ubuntu0.24.04.1)

Einschalten musst du danach nichts. Die Installation hat den Dienst aktiviert, und der Cluster ist online.

systemctl is-enabled postgresql
pg_lsclusters

enabled

Ver Cluster Port Status Owner    Data directory              Log file
16  main    5432 online postgres /var/lib/postgresql/16/main /var/log/postgresql/postgresql-16-main.log

Eine Sache sieht hier beim ersten Mal wie ein Fehler aus. Frag systemd nach der Unit postgresql.service, und die Antwort beginnt so.

systemctl status postgresql --no-pager --lines=0

● postgresql.service - PostgreSQL RDBMS
     Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; preset: enabled)

Die nächste Zeile beginnt mit Active: active (exited). Es ist nichts kaputt, und der Server hat nicht angehalten. Diese Unit hat keinen laufenden Prozess, und der Server läuft in einer zweiten Unit, postgresql@16-main.service.

systemctl status postgresql@16-main --no-pager --lines=0

● postgresql@16-main.service - PostgreSQL Cluster 16-main
     Loaded: loaded (/usr/lib/systemd/system/postgresql@.service; enabled-runtime; preset: enabled)

Deren nächste Zeile beginnt mit Active: active (running). Der Server lauscht auf Port 5432 nur dieser Maschine (127.0.0.1) und nicht im Netz.

sudo ss -ltnp | grep 5432

LISTEN 0      200        127.0.0.1:5432      0.0.0.0:*    users:(("postgres",pid=4085,fd=6))

3. Die erste Anmeldung

Die Installation hat einen Datenbankbenutzer angelegt, postgres, einen Superuser ohne Passwort, und einen Systembenutzer mit demselben Namen, den es vorher nicht gab. Du meldest dich an, indem du für einen Befehl dieser Systembenutzer wirst. An der Eingabeaufforderung von psql hat das Skript \conninfo eingetippt, das zeigt, wie du verbunden bist, und \q, das psql beendet.

sudo -u postgres psql

psql (16.15 (Ubuntu 16.15-0ubuntu0.24.04.1))
Type "help" for help.

postgres=# \conninfo
You are connected to database "postgres" as user "postgres" via socket in "/var/run/postgresql" at port "5432".
postgres=# \q

Mit -c führt psql einen Befehl aus und beendet sich. Der Rest dieser Seite benutzt diese Form, weil so jeder Schritt in eine Zeile passt. Der erste der nächsten beiden Befehle listet die Datenbankbenutzer auf, und der zweite zeigt, ob jeder von ihnen ein Passwort hat.

sudo -u postgres psql -c "\du"

                             List of roles
 Role name |                         Attributes
-----------+------------------------------------------------------------
 postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS

sudo -u postgres psql -c "SELECT rolname, rolpassword IS NULL AS no_password FROM pg_authid WHERE rolcanlogin;"

 rolname  | no_password
----------+-------------
 postgres | t
(1 row)

Das t bedeutet „true“, also wahr. Der Superuser hat kein Passwort, und das wird in Abschnitt 7 noch einmal wichtig.

4. Der Fehler: Peer authentication failed for user "postgres"

Der naheliegende Weg, sich als Superuser anzumelden, ist, ihn mit -U anzugeben. Auf einer frischen Installation wird das abgelehnt.

psql -U postgres

psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  Peer authentication failed for user "postgres"

Die Meldung sagt nicht, was nicht zusammengepasst hat. Das Protokoll des Servers sagt es, ein paar Zeilen vor seinem Ende.

sudo tail -n 4 /var/log/postgresql/postgresql-16-main.log

postgres@postgres LOG:  provided user name (postgres) and authenticated user name (ubuntu) do not match

Der angegebene Name („provided“) ist der Datenbankbenutzer, den du mit -U verlangt hast. Der authentifizierte Name („authenticated“) ist der Systembenutzer, unter dem dein Befehl läuft, und den erfährt der Server vom Betriebssystem und nicht aus dem, was du eintippst. Die Peer-Authentifizierung vergleicht die beiden und lässt dich herein, wenn sie gleich sind. Mehr tut peer auf dieser Installation nicht, und deshalb hat sudo -u postgres psql in Abschnitt 3 funktioniert und dies hier nicht. Peer gibt es nur für Verbindungen über den Socket dieser Maschine (im Handbuch der Abschnitt zur Peer-Authentifizierung).

Mit welcher Methode eine Verbindung geprüft wird, steht in der Datei pg_hba.conf. Hier ist unsere, wie die Installation sie hinterlassen hat, ohne Kommentare und Leerzeilen.

sudo grep -v -e "^#" -e "^$" /etc/postgresql/16/main/pg_hba.conf

local   all             postgres                                peer
local   all             all                                     peer
host    all             all             127.0.0.1/32            scram-sha-256
host    all             all             ::1/128                 scram-sha-256
local   replication     all                                     peer
host    replication     all             127.0.0.1/32            scram-sha-256
host    replication     all             ::1/128                 scram-sha-256

Die Zeilen mit replication sind für Verbindungen, die die Datenbank auf einen anderen Server kopieren, und gelten nicht für eine Anmeldung. Die übrigen geht der Server von oben nach unten durch, nimmt die erste, die zur Art der Verbindung, zur Datenbank und zum Benutzer passt, und versucht danach keine weitere (das Handbuch zu pg_hba.conf). Eine local-Verbindung läuft über den Socket, und für die steht in der Datei peer. Eine host-Verbindung kommt über TCP, das diese Datei nur von dieser Maschine aus annimmt, und für die will sie ein Passwort, mit der Methode scram-sha-256.

Damit bleiben zwei Wege hinein. Du kannst der Systembenutzer sein, wie in Abschnitt 3. Oder der Datenbankbenutzer hat ein Passwort, und dann kommst du entweder über TCP (Abschnitt 5) oder änderst für diesen einen Benutzer eine Zeile dieser Datei (Abschnitt 6).

Viele Antworten auf diesen Fehler raten, peer in trust zu ändern. Wir tun das nicht. Laut Handbuch lässt trust jeden, der den Server erreichen kann, als beliebigen Datenbankbenutzer herein, auch als Superuser, ohne Passwort.

5. Ein eigener Benutzer und eine eigene Datenbank

Eine Anwendung sollte sich nicht als Superuser anmelden. Gib ihr einen Benutzer mit Passwort und eine Datenbank, die diesem Benutzer gehört. Wähl ein eigenes Passwort, denn unseres ist ein Beispiel auf einer öffentlichen Seite.

sudo -u postgres psql -c "CREATE ROLE app LOGIN PASSWORD 'example-password-change-me';"
sudo -u postgres createdb --owner=app appdb

CREATE ROLE

Am Socket trifft der neue Benutzer auf dieselbe Regel wie zuvor, weil kein Systembenutzer app heißt.

psql -U app -d appdb

psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  Peer authentication failed for user "app"

Lösung eins: über TCP kommen

Die erste Lösung ändert keine Datei. Mit -h localhost kommt die Verbindung über TCP und ist damit eine host-Verbindung, und solche Verbindungen fragen nach dem Passwort. Das Skript hat das Passwort an der Eingabeaufforderung eingetippt, wo ein Terminal es nicht anzeigt.

psql -h localhost -U app -d appdb -c "\conninfo"

Password for user app:
You are connected to database "appdb" as user "app" on host "localhost" (address "127.0.0.1") at port "5432".
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)

Für den Rest der Seite übergibt das Skript psql das Passwort in der Variablen PGPASSWORD, so bleibt ein Schritt eine Zeile ohne Eingabeaufforderung. Damit kann der neue Benutzer in seiner Datenbank arbeiten.

PGPASSWORD=example-password-change-me psql -h localhost -U app -d appdb -c "CREATE TABLE notes (id integer PRIMARY KEY, body text); INSERT INTO notes VALUES (1, 'hello'); SELECT * FROM notes;"

CREATE TABLE
INSERT 0 1
 id | body
----+-------
  1 | hello
(1 row)

Aus dem Handbuch, nicht aus unserem Lauf: Ein Passwort in eine Befehlszeile zu schreiben, auf eine der beiden Arten oben, ist etwas, das unser Skript tut, und keine Gewohnheit zum Nachmachen. Das Handbuch empfiehlt PGPASSWORD nicht, weil manche Betriebssysteme andere Benutzer die Umgebungsvariablen eines Prozesses sehen lassen, und verweist stattdessen auf eine Passwortdatei (34.15 Environment Variables). \password von psql, das Abschnitt 7 ausführt, setzt ein Passwort so, dass es laut Handbuch „does not appear in cleartext in the command history, the server log, or elsewhere“ (psql im Handbuch von PostgreSQL 16). Über ein Passwort, das wie oben hinter CREATE ROLE … PASSWORD steht, sagt das Handbuch, dass es „might also be logged in the client's command history or the server log“ (CREATE ROLE, Notes).

6. Lösung zwei: ein Passwort am Socket, für diesen einen Benutzer

Wenn ein Programm den Socket als app benutzen muss, braucht dieser Benutzer eine eigene Zeile in pg_hba.conf. Die Zeile muss über der Zeile für alle stehen, weil der erste Treffer gewinnt. Heb dir eine Kopie der Datei auf, bevor du sie anfasst. In einem Editor würdest du die eine Zeile einfügen, die das diff unten zeigt, und das Skript hat dasselbe mit sed getan.

sudo cp /etc/postgresql/16/main/pg_hba.conf /etc/postgresql/16/main/pg_hba.conf.before
sudo sed -i "/^local[[:space:]]\+all[[:space:]]\+all[[:space:]]\+peer/i local   all             app                                     scram-sha-256" /etc/postgresql/16/main/pg_hba.conf
sudo diff /etc/postgresql/16/main/pg_hba.conf.before /etc/postgresql/16/main/pg_hba.conf || true

122a123
> local   all             app                                     scram-sha-256

Die Zahlen sind Zeilennummern unserer Datei (122a123 hier, und 118, 123 und 124 unten), bei dir können sie anders sein. Es kommt darauf an, dass die neue Zeile über local all all peer steht.

Mit der Sicht pg_hba_file_rules kannst du die Änderung prüfen, bevor sie gilt. Sie zeigt die Datei, wie sie jetzt ist, nicht das, was der Server geladen hat, und in ihrer letzten Spalte steht ein Fehler bei einer Zeile, die der Server nicht verwenden konnte (das Handbuch zu dieser Sicht).

sudo -u postgres psql -c "SELECT line_number, type, database, user_name, address, auth_method, error FROM pg_hba_file_rules;"

 line_number | type  |   database    | user_name  |  address  |  auth_method  | error
-------------+-------+---------------+------------+-----------+---------------+-------
         118 | local | {all}         | {postgres} |           | peer          |
         123 | local | {all}         | {app}      |           | scram-sha-256 |
         124 | local | {all}         | {all}      |           | peer          |

Die neue Zeile ist da, über der Zeile für alle, und ihre letzte Spalte ist leer. Der Server benutzt sie aber noch nicht. Er liest die Datei, wenn er startet und wenn man ihn neu laden lässt, und bis dahin scheitert die Anmeldung wie zuvor.

PGPASSWORD=example-password-change-me psql -U app -d appdb -c "\conninfo"

psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  Peer authentication failed for user "app"

Nach einem Reload funktioniert derselbe Befehl.

sudo systemctl reload postgresql
PGPASSWORD=example-password-change-me psql -U app -d appdb -c "\conninfo"

You are connected to database "appdb" as user "app" via socket in "/var/run/postgresql" at port "5432".

Die neue Zeile gilt für einen Benutzer, sonst hat sich also nichts geändert. Wir haben beide früheren Anmeldungen nach dem Reload noch einmal ausgeführt: Der Systembenutzer kommt weiterhin ohne Passwort hinein, und psql -U postgres scheitert weiterhin mit dem Peer-Fehler.

sudo -u postgres psql -c "\conninfo"

You are connected to database "postgres" as user "postgres" via socket in "/var/run/postgresql" at port "5432".

7. Wenn etwas anderes schiefgeht

Das sind weitere Fehler, die dir auf einer neuen Installation begegnen können. Wir haben jeden davon selbst ausgelöst, und nach jedem steht seine Lösung oder der Abschnitt, in dem sie steht.

role "ubuntu" does not exist

psql

psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  role "ubuntu" does not exist

Ohne -U verlangt psql den Datenbankbenutzer mit dem Namen deines Systembenutzers, und den gibt es nicht. Gib entweder einen Benutzer an, den es gibt (-U app), oder leg einen mit deinem eigenen Namen an.

sudo -u postgres createuser "$(whoami)"

database "ubuntu" does not exist, database "app" does not exist

Mit dem Benutzer, den createuser angelegt hat, kommt derselbe Befehl weiter und bleibt an der nächsten Sache hängen, die fehlt.

psql

psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  database "ubuntu" does not exist

PGPASSWORD=example-password-change-me psql -h localhost -U app

psql: error: connection to server at "localhost" (127.0.0.1), port 5432 failed: FATAL:  database "app" does not exist

Ohne -d verlangt psql eine Datenbank, die so heißt wie der Benutzer. Die Anmeldung selbst hat beide Male funktioniert, und nur die Datenbank fehlte. Die Lösung ist also, die Datenbank anzugeben, die du meinst.

psql -d appdb -c "\conninfo"

You are connected to database "appdb" as user "ubuntu" via socket in "/var/run/postgresql" at port "5432".

Dieselbe Meldung bekommst du bei einem vertippten Namen, und sudo -u postgres psql -l listet die Datenbanken auf, die es gibt.

sudo -u postgres psql -d shop

psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  database "shop" does not exist

password authentication failed for user "app"

Das Passwort ist falsch. psql gibt diese Meldung zweimal aus.

PGPASSWORD=wrong psql -h localhost -U app -d appdb

psql: error: connection to server at "localhost" (127.0.0.1), port 5432 failed: FATAL:  password authentication failed for user "app"
connection to server at "localhost" (127.0.0.1), port 5432 failed: FATAL:  password authentication failed for user "app"

Wenn das Passwort verloren ist, kann der Superuser ein neues setzen. Das alte gilt dann nicht mehr: Nach der Änderung wird das erste Passwort abgelehnt.

sudo -u postgres psql -c "ALTER ROLE app PASSWORD 'another-example-password';"
PGPASSWORD=example-password-change-me psql -h localhost -U app -d appdb -c "\conninfo"

ALTER ROLE

psql: error: connection to server at "localhost" (127.0.0.1), port 5432 failed: FATAL:  password authentication failed for user "app"
connection to server at "localhost" (127.0.0.1), port 5432 failed: FATAL:  password authentication failed for user "app"

Diese Form schreibt das neue Passwort in den Befehl. An einem Terminal fragt \password stattdessen danach, zweimal, und zeigt nichts davon an. Das Skript hat a-third-example-password eingetippt, und die Anmeldung danach benutzt dieses.

sudo -u postgres psql -c "\password app"

Enter new password for user "app":
Enter it again:

PGPASSWORD=a-third-example-password psql -h localhost -U app -d appdb -c "\conninfo"

You are connected to database "appdb" as user "app" on host "localhost" (address "127.0.0.1") at port "5432".
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)

password authentication failed for user "postgres"

Über TCP wird der Superuser wie alle anderen nach einem Passwort gefragt, und was immer du angibst, wird abgelehnt.

PGPASSWORD=anything psql -h localhost -U postgres

psql: error: connection to server at "localhost" (127.0.0.1), port 5432 failed: FATAL:  password authentication failed for user "postgres"
connection to server at "localhost" (127.0.0.1), port 5432 failed: FATAL:  password authentication failed for user "postgres"

Die Meldung ist die für ein falsches Passwort, aber hier kann kein Passwort richtig sein. Warum, sagt nur das Protokoll des Servers.

sudo tail -n 4 /var/log/postgresql/postgresql-16-main.log

postgres@postgres DETAIL:  User "postgres" has no password assigned.

Der Superuser hat nach der Installation kein Passwort (Abschnitt 3), und ein Benutzer ohne Passwort scheitert an einer Passwortprüfung immer (das Handbuch zur Passwort-Authentifizierung). Melde dich an wie in Abschnitt 3, oder nimm einen eigenen Benutzer.

8. Wenn du ein neueres PostgreSQL brauchst, als Ubuntu mitliefert

Ubuntu behält für die Lebensdauer eines Release eine PostgreSQL-Version, und für 24.04 ist das 16. Das PostgreSQL-Projekt hat ein eigenes Paket-Repository mit neueren Versionen. Wir haben es auf einer zweiten frischen Maschine derselben Art ausprobiert, ebenfalls am 5. Oktober 2026, mit den Befehlen von der Download-Seite des Projekts für Ubuntu. Das Skript des Projekts liest einen Tastendruck, bevor es etwas schreibt, aber unter seinen Optionen ist y. Wir haben es mit -y ausgeführt, und es hat nicht gewartet.

sudo apt update
sudo apt install -y postgresql-common
grep -n -e getopts -e "read " /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh || true

27:while getopts "c:f:h:ipstv:y" opt ; do
128:    read enter

sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh -y

This script will enable the PostgreSQL APT repository on apt.postgresql.org on
your system. The distribution codename used will be noble-pgdg.

sudo apt install -y postgresql-18
psql --version

psql (PostgreSQL) 18.6 (Ubuntu 18.6-1.pgdg24.04+2)

Die Regeln für die Anmeldung sind dieselben wie bei Ubuntus eigenem Paket, und der Fehler auch.

sudo grep -v -e "^#" -e "^$" /etc/postgresql/18/main/pg_hba.conf

local   all             postgres                                peer
local   all             all                                     peer
host    all             all             127.0.0.1/32            scram-sha-256
host    all             all             ::1/128                 scram-sha-256
local   replication     all                                     peer
host    replication     all             127.0.0.1/32            scram-sha-256
host    replication     all             ::1/128                 scram-sha-256

psql -U postgres

psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  Peer authentication failed for user "postgres"

Auf dieser zweiten Maschine sind wir nur bis zur Installation und zum ersten Fehler gegangen. Alles andere auf dieser Seite lief mit Version 16 aus Ubuntus Archiv, nicht mit 18.

9. Wie du es rückgängig machst

Einer der beiden Befehle in diesem Abschnitt kann deine Datenbanken löschen. Mach dir klar, welcher, bevor du einen von beiden eintippst. apt remove nimmt die Programme weg und behält deine Konfiguration, deine Datenbanken und das Protokoll. apt purge fragt, ob es die auch löschen soll, und löscht sie, wenn du mit „yes“ antwortest. In einer Form, die weiter unten steht, fragt es gar nicht.

Remove: Die Programme gehen, die Daten bleiben

sudo apt remove -y postgresql postgresql-16 postgresql-client-16 postgresql-common postgresql-client-common
sudo ls /etc/postgresql/16/main
sudo ls /var/lib/postgresql/16/main
ls /var/log/postgresql

pg_hba.conf
pg_hba.conf.before
pg_ident.conf
postgresql.conf

PG_VERSION
base
global

postgresql-16-main.log

Die Konfiguration, der Datenordner und das Protokoll sind noch da. Der Server ist es nicht. Auf Port 5432 lauscht nichts mehr, deshalb hat der nächste Befehl nichts ausgegeben und mit einem Fehler geendet.

sudo ss -ltnp | grep 5432

Purge: Es fragt, und „no“ behält deine Daten

An einem Terminal ohne -y eingetippt, stellt das Purge zwei Fragen. apt fragt, ob es weitermachen soll, und dann fragt das Paket, ob es die Datenbanken löschen soll. Das Skript hat bei der ersten y und bei der zweiten no eingetippt.

sudo apt purge postgresql postgresql-16 postgresql-client-16 postgresql-common postgresql-client-common

Do you want to continue? [Y/n] y

Removing the PostgreSQL server package will leave existing database clusters
intact, i.e. their configuration, data, and log directories will not be removed.
On purging the package, the directories can optionally be removed.

Remove PostgreSQL directories when package is purged? [yes/no] no

Nach „no“ enthielten die drei Ordner, was sie vorher enthielten, das haben wir mit denselben drei ls-Befehlen geprüft. Eine neue Installation hat danach den Cluster wiedergefunden, mit der Datenbank aus Abschnitt 5 darin.

sudo apt install -y postgresql
sudo -u postgres psql -c "\l appdb"

 Name  | Owner | Encoding | Locale Provider | Collate |  Ctype  | ICU Locale | ICU Rules | Access privileges
-------+-------+----------+-----------------+---------+---------+------------+-----------+-------------------
 appdb | app   | UTF8     | libc            | C.UTF-8 | C.UTF-8 |            |           |
(1 row)

Purge mit der Antwort „yes“: Die Datenbanken werden gelöscht

Wir haben denselben Befehl noch einmal ausgeführt, und diesmal hat das Skript y und dann yes eingetippt.

sudo apt purge postgresql postgresql-16 postgresql-client-16 postgresql-common postgresql-client-common

Remove PostgreSQL directories when package is purged? [yes/no] yes

Dropping cluster main...

ls -ld /etc/postgresql /var/lib/postgresql /var/log/postgresql 2>&1

ls: cannot access '/var/lib/postgresql': No such file or directory
ls: cannot access '/var/log/postgresql': No such file or directory
drwxr-xr-x 3 postgres postgres 4096 Oct  5 12:47 /etc/postgresql

Die Daten und das Protokoll sind weg, und nichts fragt ein zweites Mal.

Die Form, die löscht, ohne zu fragen

Es gibt eine Form des Purge, die gar nichts fragt. Mit DEBIAN_FRONTEND=noninteractive wird dem Paket gesagt, dass es nicht fragen soll, und mit -y fragt auch apt nicht. Wir haben noch einmal installiert, damit es einen Cluster zu verlieren gab, und sie ausgeführt. Sie hat nichts gefragt und den Cluster gelöscht. Benutz diese Form nur, wo du es so meinst, in einem Skript für eine Maschine, die du wegwirfst.

sudo DEBIAN_FRONTEND=noninteractive apt purge -y postgresql postgresql-16 postgresql-client-16 postgresql-common postgresql-client-common

Dropping cluster main...

dpkg: warning: while removing postgresql-common, directory '/etc/postgresql' not empty so not removed

Was noch da ist, und wie du auch das entfernst

Ein paar Dinge überleben sogar das Purge. In /etc/postgresql bleibt, was die Pakete nicht angelegt haben, und das war hier unsere Kopie aus Abschnitt 6. Wir haben den Ordner gelöscht und dann apt autoremove ausgeführt. Das entfernt jedes Paket, das apt für nicht mehr benötigt hält, nicht nur die von PostgreSQL. Auf unserer frischen Maschine waren das die Pakete, die die Installation mitgebracht hatte. Auf einer Maschine mit Vorgeschichte lies seine Liste, bevor du -y anhängst.

sudo find /etc/postgresql

/etc/postgresql
/etc/postgresql/16
/etc/postgresql/16/main
/etc/postgresql/16/main/pg_hba.conf.before

sudo rm -r /etc/postgresql
sudo apt autoremove -y

The following packages will be REMOVED:
  libcommon-sense-perl libjson-perl libjson-xs-perl libllvm17t64 libpq5
  libtypes-serialiser-perl ssl-cert

Selbst nach all dem war die Maschine nicht so, wie wir sie vorgefunden hatten. Das Paket ssl-cert war entfernt, aber nicht mit Purge (Zustand rc), das Zertifikat und der Schlüssel, die es bei der Installation angelegt hatte, waren noch da, und ebenso der Systembenutzer postgres und die Gruppen postgres und ssl-cert. Wir hatten vor dem ersten apt-Befehl nach dem Benutzer, den beiden Gruppen und dem Paket gesucht und nichts gefunden, und das Zertifikat und der Schlüssel tragen beide die Zeit der Installation, auf die Minute. Auf einer Maschine, auf der etwas anderes ssl-cert oder einen Benutzer namens postgres verwendet, lass sie stehen. Auf unserer haben die Befehle des letzten Blocks sie entfernt, und danach haben dieselben Prüfungen nichts mehr gefunden.

dpkg -l | grep "^rc"
sudo ls -l /etc/ssl/certs/ssl-cert-snakeoil.pem /etc/ssl/private/ssl-cert-snakeoil.key
getent passwd postgres
getent group postgres ssl-cert

rc  ssl-cert                         1.1.2ubuntu1                                     all          simple debconf wrapper for OpenSSL

-rw-r--r-- 1 root root     1135 Oct  5 12:47 /etc/ssl/certs/ssl-cert-snakeoil.pem
-rw-r----- 1 root ssl-cert 1704 Oct  5 12:47 /etc/ssl/private/ssl-cert-snakeoil.key

postgres:x:110:114:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash

postgres:x:114:
ssl-cert:x:113:postgres

sudo apt purge -y ssl-cert
sudo deluser postgres
sudo delgroup ssl-cert

info: Removing user `postgres' ...

info: Removing group `ssl-cert' ...

Wie viel diese Datenbank aushält

PostgreSQL zu installieren ist der leichte Teil. Wie viel Last ein PostgreSQL aushält, ist eine andere Frage, und die haben wir auf echten Maschinen gemessen. Die Seiten dazu sind englisch: wie viele Anfragen pro Sekunde ein Postgres schafft, wie groß sein Connection-Pool sein sollte, und wie viele Nutzer ein 12-Dollar-Server mit Nginx, Node.js und Postgres trägt.

Der Playground ist während der privaten Vorschau nur mit Einladung zugänglich: trag dich in die Warteliste ein, um eine Einladung zu bekommen.

Quellen

• Unser eigener Lauf: ein Skript auf zwei frischen Maschinen mit Ubuntu 24.04 am 5. Oktober 2026. Jeder Befehl und jede Ausgabe auf dieser Seite stammt aus dem Skript und seinem Protokoll, und der eine Absatz, der als Handbuch gekennzeichnet ist, stammt aus dem Handbuch.
• Das PostgreSQL-Projekt, Linux downloads (Ubuntu): Ubuntu liefert eine PostgreSQL-Version pro Release; das Apt-Repository des Projekts und seine Befehle.
• Handbuch von PostgreSQL 16, 21.1 The pg_hba.conf File: Die erste passende Zeile wird verwendet und keine andere; local und host; trust; die Datei wird beim Start und bei einem Reload gelesen. Und 54.9 pg_hba_file_rules: Die Sicht zeigt die Datei, wie sie ist, mit einem Fehler bei einer Zeile, die nicht verwendet werden konnte.
• Handbuch von PostgreSQL 16, 21.9 Peer Authentication und 21.5 Password Authentication.
• Handbuch von PostgreSQL 16, psql: -c, \q, \password, die voreingestellten Namen von Benutzer und Datenbank; 34.15 Environment Variables: PGPASSWORD; und CREATE ROLE, Notes: ein Passwort, das im Befehl steht.
• Dokumentation von Ubuntu Server, Install and configure PostgreSQL: Auf Ubuntu ist peer die Voreinstellung für lokale Verbindungen und scram-sha-256 für Host-Verbindungen.