
This module has you put into service a PostgreSQL 18 database on a Linux server, then lock it down: at the end, the instance (the running PostgreSQL server) starts on its own, answers authorized clients, carries the settings you asked for, and refuses everything else. It is aimed at a system administrator, a DevOps engineer or a backend developer who can use the Linux command line and read a simple SQL query, but has never administered PostgreSQL. It takes five lessons, about three hours.
What do you do in this module?
PostgreSQL is an open source relational database management system. This module does not teach how to write queries, which belongs to the SQL course (in French): an operator mostly needs to know where the files live, which processes run, who is allowed in and how to check that a setting is really applied. The module is built on these four questions, in the order they come up.
The first lesson, Discover PostgreSQL, has no hands-on step: it lays down the vocabulary (cluster, instance, database, schema, role) and the mental model of the server: the data directory (PGDATA), the processes and the transaction log (WAL). It comes first because all the others use these words, and because a cluster (here, a data directory, unrelated to high availability) puzzles anyone who installs without having read this lesson.
The four other lessons are hands-on, and each is validated by a lab:
- Install PostgreSQL 18 from the PGDG repository (the PostgreSQL project's own), recognize the cluster it creates and check that it comes back after a restart;
- Administer an instance with psql: connect with
psql, the command-line client, over the socket (the local channel) then over TCP, open network access and read the real state of the server; - Configure PostgreSQL: memory, connections and logs, with the difference between a reload and a restart;
- Control access: the rules of
pg_hba.conf(the file that decides who may connect), roles with least privilege (no more rights than needed) and enforced TLS encryption.
Why this order?
You install before you connect, you connect before you tune, and you tune before you lock down, because each step hands the next one an observable state. A freshly installed instance only listens on the loopback (the address 127.0.0.1, which only the machine itself can reach). Opening it to the network is the psql lesson's job. Configuring it comes next, on a server you know how to reach. Locking it down comes last, because hardening (reducing what the server lets anyone do) applied to an instance you cannot yet query is hard to verify.
Each lesson also keeps to a clear boundary. The vocabulary stays in the architecture lesson, the parameter contexts (what decides whether a setting applies on a reload or only after a restart) in the configuration lesson, and the roles and TLS in the access lesson. When a lesson touches another one's subject, it points there instead of repeating it.
What you will be able to do at the end
By the end of the module you can explain what a PostgreSQL cluster is and where its files live, install a version 18 instance you can recognize by its package and its cluster, connect over both channels and prove which one is active, apply a setting and know whether it took effect, and refuse a cleartext connection or a role without rights. These skills are the same whether you run a database on a virtual machine or on a dedicated server.
The later levels of the training cover backup and restore, monitoring and replication. They assume a healthy, locked-down instance, which is why this module comes first. If you are still hesitating between engines, the PostgreSQL, MySQL and SQLite comparison justifies the choice, and the training overview details how it is organized, along with the MySQL option (in French).
Which version and environment does it use?
The module targets PostgreSQL 18, installed from the official PGDG repository on Debian; the installation lesson also covers Rocky Linux, RHEL and AlmaLinux. The labs run on Debian 13 virtual machines. Each lesson states the exact version its outputs come from: a value read on your server may differ by a minor version without changing the approach.