WalShadow : une réplication Postgres vers ClickHouse en sub-seconde via le WAL physique
En bref
- ClickHouse lance WalShadow, un moteur open source qui réplique les données Postgres directement depuis le flux WAL physique (plutôt que via la décoding logique).
- Latence commit-to-visible : environ 200 ms, contre ~10 secondes pour PeerDB (l'ancien outil de ClickHouse).
- Débit soutenu : 289K lignes/sec, soit 4x plus rapide que PeerDB, sans surcharger l'instance Postgres source.
- L'approche consomme le même flux WAL que les standby physiques Postgres, éliminant les slots de réplication logique et réduisant la charge opérationnelle.
Ce que dit la source
ClickHouse présente WalShadow comme une alternative à la réplication logique CDC. Le problème posé : les outils CDC traditionnels (dont PeerDB, l'ancien outil maison de ClickHouse) reposent sur `wal_level = logical` et introduisent une latence importante (~10 secondes) et une charge asymétrique sur l'instance Postgres. WalShadow contourne cela en consommant le WAL physique brut, le même flux utilisé par les standby Postgres natifs, décodé en dehors de la base source via une architecture parallélisée en quatre étapes : suivi du schéma (via une instance shadow Postgres), décodage distribué des changements, construction de blocs ClickHouse natifs, et insertion en parallèle.
- Latence de 200 ms commit-to-visible (visibilité immédiate des données), comparée à ~10 secondes pour PeerDB et ~50 ms pour un standby Postgres natif, soit un gain de 50x sur la réplication logique
- Débit de 289K lignes/sec, matching quasi-exact du débit source Postgres (~290K/sec), contre 120K/sec pour PeerDB
- N'utilise pas `wal_level = logical` (réplication logique) mais `wal_level = replica`, éliminant les slots de réplication logique et leur overhead opérationnel
- Architecture parallélisée en quatre étapes (suivi du schéma, décodage, batchage ClickHouse, insertion) sans conversion intermédiaire JSON ou Kafka
- Supporte le cycle complet de réplication : charge initiale, réplication continue, évolution de schéma, recovery après redémarrage, changements complexes (ADD/DROP/RENAME COLUMN)
- Disponible en open source sur GitHub, avec une version privée preview pour ClickHouse Managed Postgres (car la plupart des services Postgres gérés n'exposent pas le WAL physique)
Dans les commentaires
Débat limité, peu de substance, mais intéressant sur le plan technique. Les rares commentaires soulèvent des questions très pointues (TOAST, compatibilité avec Supabase) sans contester l'approche.
- Un commentateur note que c'est la première fois que quelqu'un construit un CDC sur `wal_level = replica` plutôt que la voie logique habituelle, et spécule que ce type de travail bas niveau aurait été inaccessible sans outillage IA récent
- Incertitude non levée sur le traitement des données TOAST (blobs stockés externement en Postgres) et leur fusion lors de réplications partielles : c'est un détail que le commentaire qualifie d'habituel problème
- Question d'applicabilité : un utilisateur demande si WalShadow fonctionne avec Supabase (Postgres managé) et évoque son approche actuelle par polling sur une read-only DB, laissant ouvert le besoin de compatibilité avec des services tiers qui n'exposent pas le WAL physique
Notre lecture
WalShadow est une innovation architecture légitime, pas du marketing pur. L'approche WAL physique est techniquement solide et les benchmarks (200 ms de latence, 4x le débit de PeerDB) sont crédibles dans ce contexte étroit. Le vrai frein à l'adoption ne sera pas technique mais opérationnel : WalShadow exige l'accès au WAL physique, ce que seule ClickHouse Managed Postgres garantit. Pour les autres (Supabase, RDS, etc.), l'outil reste hors de portée. À surveiller surtout pour les clients ClickHouse utilisant leur propre Postgres ou leur offre managée. Pour tous les autres, la question de la compatibilité avec les services hébergés est un blocage majeur non résolu par cette annonce.