Kafka est rapide — moi, j’utiliserai Postgres

• Benchmark des performances publish/subscribe (pub-sub) et queue de Postgres, montrant qu’une base de données unique peut potentiellement remplacer un système de messagerie
• Sur un nœud unique de 4 vCPU, 5 036 écritures/s et 25 183 lectures/s, avec un débit similaire maintenu dans un environnement répliqué à 3 nœuds, pour une latence de bout en bout de 186 ms (p99)
• Sur un grand nœud de 96 vCPU, performances atteignant 238 MiB/s en écriture et 1,16 GiB/s en lecture, avec une marge confortable puisque l’utilisation CPU reste sous les 10 %
• Les tests de queue montrent aussi 2 885 opérations/s sur un nœud unique et 2 397 en environnement répliqué, des performances suffisantes pour la plupart des entreprises
• La démonstration montre qu’au lieu d’un système distribué complexe, une infrastructure Postgres unique peut suffire pour traiter des charges de travail de plusieurs MB/s, en défendant une approche pragmatique : « utilisez la technologie la plus simple jusqu’à ce qu’elle ne suffise plus »

---

Deux camps dans le choix technologique

• L’industrie tech se divise entre un camp piloté par les buzzwords et un camp guidé par le bon sens
  • Le premier est attiré par des termes marketing comme « temps réel », « scalabilité infinie » ou « propulsé par l’IA »
  • Le second privilégie la simplicité et le pragmatisme, en évitant la complexité inutile
• Deux tendances récentes renforcent ce second camp : Small Data et la renaissance de Postgres
  • Les volumes de données diminuent tandis que le matériel devient plus puissant
  • Postgres peut remplacer, à lui seul, diverses solutions spécialisées (jsonb, pgvector, tsvector, etc.)

Aperçu du benchmark

• Objectif : mesurer jusqu’où Postgres peut monter en charge pour la messagerie pub/sub et le traitement de queues
• Environnement de test : AWS EC2 c7i.xlarge (4 vCPU) et c7i.24xlarge (96 vCPU)
• Comparaison de trois configurations
  • nœud unique
  • cluster répliqué à 3 nœuds
  • grand nœud unique

Résultats du benchmark Pub/Sub

• Nœud unique 4 vCPU
  • écriture 4,8 MiB/s (5 036 msg/s), lecture 24,6 MiB/s (25 183 msg/s), latence 60 ms (p99)
  • CPU à 60 %, disque à 46 MiB/s en écriture
• Réplication 3 nœuds, 4 vCPU
  • écriture 4,9 MiB/s, lecture 24,5 MiB/s, latence 186 ms (p99)
  • débit maintenu, pour un coût annuel d’environ 11 514 $
• Nœud unique 96 vCPU
  • écriture 238 MiB/s (243k msg/s), lecture 1,16 GiB/s (1,2M msg/s), latence 853 ms (p99)
  • CPU sous les 10 %, le goulot d’étranglement venant de la vitesse d’écriture par partition
• Conclusion : des performances suffisamment élevées pour rivaliser avec Kafka sur des charges faibles à moyennes, avec une architecture simple capable de traiter plusieurs dizaines de MiB/s

Résultats du benchmark Queue

• Implémentation d’une queue simple basée sur SELECT FOR UPDATE SKIP LOCKED
• Nœud unique 4 vCPU
  • 2,81 MiB/s (2 885 msg/s), latence 17,7 ms (p99), CPU à 60 %
• Réplication 3 nœuds, 4 vCPU
  • 2,34 MiB/s (2 397 msg/s), latence 920 ms (p99), CPU à 60 %
• Nœud unique 96 vCPU
  • 19,7 MiB/s (20 144 msg/s), latence 930 ms (p99), CPU à 40–60 %
• Même avec un seul nœud, les besoins de débit en queue de la plupart des entreprises peuvent être couverts

Quand choisir Postgres

• Dans la plupart des cas, choisir Postgres par défaut est rationnel
  • les messages peuvent être débogués, modifiés et joints en SQL
  • exploitation plus simple et maintenance plus facile que Kafka
• Kafka est optimisé pour la très haute performance, mais représente souvent un choix excessif pour de petites charges
• Rappel de l’avertissement de Donald Knuth : « l’optimisation prématurée est la racine de tous les maux »
  • jusqu’à plusieurs MB/s, Postgres suffit largement

L’approche MVI (Minimum Viable Infrastructure)

• Minimum Viable Infrastructure : construire le système minimal avec des technologies déjà maîtrisées par l’organisation
  • Postgres est largement adopté et le recrutement de profils compétents y est facile
  • moins il y a de composants, plus la charge opérationnelle et le risque de panne diminuent
• L’introduction de technologies inutiles entraîne un surcoût organisationnel
  • hausse des coûts de formation, de monitoring, de déploiement et d’exploitation

Discussion sur la scalabilité

• Postgres est réellement capable de monter en charge
  • OpenAI utilise toujours Postgres avec une instance d’écriture unique
  • le système fonctionne de manière stable même à l’échelle de centaines de millions d’utilisateurs
• La plupart des entreprises croissent progressivement et disposent donc de plusieurs années avant de devoir remplacer leur pile technique
• Concevoir dès le départ « pour devenir viral » relève d’un surdesign
  • comparaison donnée : « c’est comme acheter un ampli Marshall pour faire la première partie de Coldplay »

Conclusion

• « Utilisez Postgres jusqu’à ce qu’il casse »
  • une technologie simple peut déjà offrir des performances très élevées
  • adopter trop tôt un système distribué complexe est inefficace
  • avec le matériel moderne, Postgres constitue un choix pragmatique capable d’absorber la plupart des charges de travail

[GN⁺]

Discussion sur Hacker News

• Appliquer le principe de Pareto à toutes les situations est une mauvaise interprétation
  Dire que Postgres couvre 80 % des cas d’usage de Kafka avec 20 % de l’effort est une affirmation sans fondement
  Le principe de Pareto n’a de sens que dans les situations où l’on observe une distribution en loi de puissance
  Il suffit simplement de dire que Postgres couvre suffisamment de cas d’usage, qu’il est stable et qu’il s’agit d’un outil éprouvé

  • Certains avancent toutefois que la correspondance entre cas d’usage et fonctionnalités pourrait elle-même suivre une loi de puissance

• D’après mon expérience, de petites charges (quelques centaines d’événements par heure) jusqu’aux grandes échelles (des milliers de milliards d’événements par heure), il faut d’abord se demander si une file est vraiment nécessaire

  1. Un simple polling de la base peut suffire
  2. Si un seul nœud peut l’absorber, un traitement serverless ou en processus unique peut convenir
  3. Si une file distribuée n’est pas indispensable, équilibrage de charge + API REST + retries asynchrones peuvent suffire
  4. Si une file distribuée est réellement nécessaire, il vaut mieux utiliser une solution dédiée comme Kafka
  • Il faut préciser clairement que Kafka n’est en réalité pas une file mais un système de logs distribués. Beaucoup le prennent à tort pour un remplaçant de MQ
  • Dans les startups, les ingénieurs ont souvent tendance à choisir des technologies complexes en pensant à leur prochaine étape de carrière plutôt qu’au projet en cours
  • Si l’architecture du code est conçue pour pouvoir prendre en charge à la fois une file basée sur PostgreSQL et une file basée sur Kafka, la migration ultérieure est plus facile
  • PostgreSQL devient facilement un goulot d’étranglement quand la charge d’écriture augmente. Les flux d’UPDATE sont particulièrement pénibles
  • En tant que développeur Java, j’ai toujours eu besoin d’une file. Le polling de base était un vrai casse-tête dans les environnements avec plusieurs consommateurs et producteurs. Les consumer groups et partitions de Kafka m’ont beaucoup aidé pour la gestion d’état

• L’approche qui consiste à utiliser Postgres pour tout est risquée
  Les verrous et niveaux de sérialisation ne sont pas intuitifs et peuvent créer des goulots de performance
  J’utilise Postgres depuis des décennies, mais il ne faut pas concevoir une architecture sur la base d’une foi aveugle

  • En cas de pic de trafic, la limite du scaling vertical pose problème. Kafka absorbe les bursts de trafic, alors que Postgres se surcharge facilement
  • Ce serait bien que Postgres ajoute une structure de file durable, mais aller au-delà de l’échelle de Redis est difficile et LISTEN/NOTIFY ne scale pas (lien connexe)
  • En réalité, avec tout stockage de données, il faut comprendre le modèle de concurrence. Il existe aussi de grandes différences entre bases relationnelles
  • Postgres ne peut pas croître indéfiniment, mais il peut traiter pas mal de données avec du batch processing et des opérations sur ligne unique
  • Personnellement, je commence d’abord avec Postgres, puis je migre vers un autre système quand un goulot apparaît

• Je pense que l’approche par table de log d’événements basée sur SQL est efficace
  Son inconvénient reste le manque d’outils côté client. Kafka a l’avantage d’un riche écosystème de bibliothèques
  Dans notre entreprise, nous avons standardisé la transmission d’événements entre services sur une base SQL (feedapi-spec)
  Ce n’est pas aussi mature que Kafka, mais cela pourrait évoluer en une pile de bibliothèques commune prenant en charge plusieurs moteurs de stockage

  • Avec les progrès des outils de génération de code basés sur les LLM, il est devenu plus facile de combler ce manque côté client
  • Pour quelqu’un qui n’aime pas Kafka, cette approche paraît bien plus séduisante

• De nos jours, les gens ont trop tendance à se laisser séduire par les nouvelles technologies
  Postgres est excellent, mais il faut utiliser l’outil adapté au problème
  Postgres n’a pas été conçu pour le pub-sub, Kafka si
  Il faut éviter cette tendance où tous les produits veulent « tout faire ». Je pense qu’il vaut mieux avoir des outils spécialisés qui font bien une chose

• Implémenter des numéros d’offset monotones croissants est un problème délicat
  Une simple séquence pose problème car l’ordre transactionnel et le moment du commit peuvent diverger

  • Une méthode consiste à avoir une table dédiée au compteur et à garantir l’ordre par verrouillage dans la même transaction (lien de référence)
  • On peut aussi garantir l’ordre dans un environnement distribué avec des horloges de Lamport ou des vector clocks (Lamport timestamp, Vector clock)
  • Plutôt que d’imposer un ordre absolu, il est plus réaliste d’attribuer des numéros par lot ou de laisser un processus séparé fixer l’ordre après le commit
  • On peut aussi éviter les traitements en double avec SELECT FOR UPDATE SKIP LOCKED

• Je me demande s’ils ont réellement benchmarké Kafka
  Les résultats obtenus dans un environnement à 96 vCPU sont aussi atteignables avec une configuration Kafka à 4 vCPU
  Les performances de Postgres sont anormalement lentes
  Si vous n’avez pas besoin de Kafka, ne l’utilisez pas, mais se vanter de faire 5k msg/s avec Postgres n’a aucun sens

  • Redpanda (implémentation compatible Kafka) traite 250 000 messages par seconde sur un simple laptop (vidéo)
  • Faire moins bien avec 288 vCPU est du gaspillage
  • Si la raison d’utiliser Postgres est simplement « parce qu’on l’a déjà », je peux le comprendre, mais il faut quand même valider avant d’ajouter une nouvelle infra
  • Kafka atteint la limite de bande passante réseau même avec peu de matériel
  • Sur AWS, faire tourner ça sur une seule instance 24xlarge est inefficace ; pour ce coût, on peut exploiter un gros cluster Kafka

• Il y a deux extrêmes : les « obsédés des nouvelles technos » et ceux qui « s’accrochent uniquement à ce qu’ils ont appris »
  Un ingénieur réaliste fait des choix pragmatiques entre les deux

  • Moi, je suis une troisième catégorie : le genre à penser que « ce qu’on a aujourd’hui est médiocre, et les nouveautés finiront probablement par l’être aussi »
  • Au final, l’important est d’examiner le problème raisonnablement et de trouver la meilleure solution
  • Par exemple, on peut essayer de remplacer Elasticsearch par Postgres, mais la qualité des fonctions de recherche reste largement supérieure dans ES

• La fonction clé de Kafka, c’est le contrôle des offsets par consommateur
  C’est indispensable dans les environnements où plusieurs équipes lisent le même topic
  Le fait de pouvoir avancer ou reculer les offsets m’a servi de bouée de sauvetage à plusieurs reprises
  Je me demande si une file Postgres peut offrir ce genre de fonctionnalité

  • Certains disent que chaque consommateur pourrait simplement gérer ses propres offsets
  • Mais dans la plupart des cas, si un haut débit n’est pas nécessaire, toute la gestion complexe des offsets de Kafka n’est pas utile
  • Au fond, c’est une question d’équilibre entre la vitesse exigée par le métier et la complexité opérationnelle

• L’opposition entre le « camp qui court après les buzzwords » et le « camp du bon sens » est elle-même erronée
  Réimplémenter Kafka avec Postgres, ce n’est pas du bon sens
  Si vous avez vraiment besoin de fonctionnalités au niveau de Kafka, utilisez simplement Kafka

  • En réalité, il ne s’agissait pas d’implémenter tout Kafka, mais seulement de deux simples requêtes pub-sub