Skip to content
Yassir Halaoui
EN
Read in English

Compétence

PostgreSQL et la couche de données : WAL, JSONB, réplication

La plupart des incidents de production que j’ai traqués finissaient dans la couche de données, alors je l’ai apprise sérieusement : comment le write-ahead log de PostgreSQL se comporte avec du CDC, quand JSONB est le bon modèle, et pourquoi la pagination par OFFSET finit par lâcher.

En bref

Yassir Halaoui maîtrise PostgreSQL en profondeur, dont JSONB, le write-ahead log, les replication slots logiques utilisés par Debezium et la pagination keyset, ainsi qu’Oracle, MySQL, Redis, Elasticsearch et Firebase. Pour une plateforme de paiement, il a construit une piste d’audit générique qui stocke des instantanés avant et après en JSONB, exposés par une API paginée en keyset.

Où je l'ai utilisée

  1. Pluxee · depuis 2025

    Exploitation de la capture de changements Debezium sur le décodage logique pgoutput de PostgreSQL, et construction d’une piste d’audit générique avec instantanés JSONB avant et après, servis par une API REST paginée en keyset.

  2. Société Générale et Docaposte

    PostgreSQL comme base de référence d’une plateforme de déclaration d’honoraires et d’une plateforme d’échange de données entre assureurs.

  3. CIH Bank · 2017 à 2022

    Des bases Oracle derrière des services bancaires en production.

  4. RevealTogether

    Redis pour l’état temps réel, et une leçon douloureuse sur les quotas de lecture d’une base documentaire, devenue l’une de ces notes de terrain.

Tout ce que couvre ce domaine

Relationnel
  • PostgreSQL
  • Oracle
  • MySQL
PostgreSQL en profondeur
  • JSONB
  • Write-ahead log
  • Replication slots logiques
  • pgoutput
  • Pagination keyset
Autres bases
  • Redis
  • Elasticsearch
  • Firebase / Firestore
Outillage
  • Flyway
  • Spring Data JPA
  • Hibernate
  • Testcontainers

En profondeur

Le write-ahead log fait partie de votre architecture

Dès que vous ajoutez de la capture de changements, le WAL cesse d’être un détail d’implémentation. Un replication slot qui n’avance plus conserve chaque segment jusqu’à remplir le disque, et sur une base partagée, c’est l’astreinte de quelqu’un d’autre qui sonne. Le WAL retenu par slot est la première alerte que je mets en place.

JSONB là où la forme change

Une piste d’audit doit rester lisible après quatre refontes des entités qu’elle enregistre. Stocker les instantanés avant et après en JSONB garantit qu’une entrée vieille de deux ans décrit encore l’enregistrement tel qu’il était. Pour des données à la forme stable sur lesquelles on fait des jointures, les colonnes classiques restent la bonne réponse.

Une pagination qui ne ralentit pas chaque mois

OFFSET oblige la base à lire puis jeter chaque ligne sautée : la page quatre cents finit en timeout sur une table qui ne fait que grossir. La pagination keyset transporte le dernier identifiant à la place, et chaque page coûte la même chose.

Questions

Pourquoi le WAL de PostgreSQL grossit-il avec un replication slot ?

Parce que le slot n’avance plus : le consommateur est arrêté, en retard ou supprimé, ou ses tables capturées sont calmes sur une base active. Surveillez le WAL retenu par slot, supprimez les slots orphelins et ajoutez un heartbeat pour les tables calmes.

Quand utiliser JSONB dans PostgreSQL ?

Quand la forme des données évolue dans le temps ou varie d’un enregistrement à l’autre : instantanés d’audit, événements, paramètres. Pas pour des données que l’on contraint, joint et interroge champ par champ tous les jours.

Pagination keyset ou offset ?

Keyset pour tout ce qui grossit : pistes d’audit, flux, listes de transactions. Offset seulement pour de petits résultats bornés où l’utilisateur a vraiment besoin d’aller à la page N.

Notes de terrain

Réalisations

Compétences liées