PostgreSQL, un programme serveur

Objectifs

À la fin de cette leçon, vous saurez :

• situer PostgreSQL dans l'architecture d'une application ;
• distinguer serveur, client, connexion, utilisateur, base et schéma ;
• comprendre le port 5432 et le modèle de permissions.

🔗 Pour vous rafraîchir la mémoire : transactions SQL

PostgreSQL n'est pas un fichier

C'est un programme serveur qui tourne en continu :

votre application (Node)
     ↓ connexion TCP
PostgreSQL (processus serveur)
     ↓ requêtes SQL
fichiers sur disque (les vraies données)

Votre code ne lit jamais les fichiers : il parle SQL à travers une connexion. Le serveur vérifie, exécute, gère la concurrence entre tous ses clients, écrit sur disque.

Le vocabulaire des couches

Notion	Rôle	Exemple
serveur	le processus PostgreSQL lui-même	votre conteneur Docker
client	tout programme qui s'y connecte	psql, votre API Node
connexion	session TCP authentifiée	postgresql://cours:...@localhost:5433/cours_full_stack
utilisateur	identité de connexion avec droits	cours
base	ensemble de tables isolé	cours_full_stack
schéma	espace de noms dans la base	public par défaut

La chaîne de connexion (DATABASE_URL) encode tout : utilisateur + mot de passe + hôte + port + base. C'est pourquoi elle vit dans .env, jamais dans le code.

Le port 5432

Par convention, PostgreSQL écoute sur TCP 5432 — vous savez maintenant lire cela : ss -lntp | grep 5432 montre le processus en écoute. Votre environnement de développement utilise 5433 côté machine parce que le port natif est occupé ; Docker mappe 5433→5432.

Utilisateurs et permissions

Chaque connexion se fait sous une identité avec des droits :

cours   → peut lire/écrire sa base
admin   → peut créer bases et utilisateurs
invité  → lecture seule

Principe du moindre privilège : l'application web ne doit PAS tourner sous l'identité admin. Une faille dans le code ne doit compromettre que ce que son compte pouvait faire.

WAL : la promesse de durabilité (aperçu)

Avant de confirmer chaque COMMIT, PostgreSQL écrit l'opération dans un journal séquentiel sur disque (WAL, write-ahead log). Un crash après COMMIT ne perd rien : au redémarrage, le journal rejoue ce qui manquait. C'est la garantie derrière « COMMIT = définitif ».

Le cache en mémoire vive

Lire sur disque coûte mille fois plus cher que lire en RAM. PostgreSQL garde donc en mémoire vive un cache de pages (paramètre phare : shared_buffers) : les pages de tables et d'index récemment utilisées y restent, prêtes à être relues sans toucher au disque.

Conséquence observable : la première exécution d'une requête est souvent plus lente que les suivantes — la première remplissait le cache, les suivantes en profitaient. C'est aussi pour cela qu'on redémarre rarement une base « chaude » sans raison : le redémarrage vide ce cache et impose de recharger depuis le disque.

Retenez l'idée (la base gère sa mémoire comme un cache entre vos requêtes et le disque) ; le réglage fin est une histoire d'administration, pas de développement.

Exercice

1. Décomposez votre DATABASE_URL : quel est l'utilisateur ? le port ? la base ?
2. Pourquoi deux applications peuvent-elles partager le même serveur PostgreSQL sans se gêner ?
3. Où vivent physiquement vos données ?

Résumé

• PostgreSQL = serveur permanent ; applications = clients via TCP.
• Connexion → utilisateur → base → schéma : couches de cloisonnement.
• COMMIT fiable grâce au WAL écrit avant confirmation.