{"id":2196,"date":"2026-10-07T15:52:14","date_gmt":"2026-10-07T13:52:14","guid":{"rendered":"https:\/\/www.loicmathieu.fr\/wordpress\/fr\/?p=2196"},"modified":"2026-10-08T16:43:31","modified_gmt":"2026-10-08T14:43:31","slug":"database-performance-postgres-vs-mysql","status":"publish","type":"post","link":"https:\/\/www.loicmathieu.fr\/wordpress\/fr\/informatique\/performance-base-de-donnees-postgres-vs-mysql\/","title":{"rendered":"Performance base de donn\u00e9es : Postgres vs. MySQL"},"content":{"rendered":"

Kestra<\/a> supporte entre autre Posstgres et MySQL comme base de donn\u00e9es, nos benchmarks internes montraient que Postgres \u00e9tait beaucoup plus performant que MySQL pour faire tourner Kestra. Nous conseillons donc g\u00e9n\u00e9ralement de faire fonctionner Kestra en production avec Postgres.<\/p>\n

Lors de nos benchmarks<\/a>, Postgres support 4000 executions\/mn avec une latence de 370ms pour nos flow type, avec une latence autour de 130ms pour un lancement unique. MySQL de son c\u00f4t\u00e9 n’arrive m\u00eame pas \u00e0 soutenir 1000 executions\/mn et a une latence autour de 160ms pour un lancement unique.<\/p>\n

Mais pourtant, certains de nos utilisateurs utilisaient MySQL sans aucun souci, cela m’a pouss\u00e9 \u00e0 me pencher sur la question.<\/p>\n

Kestra utilise sa base de donn\u00e9es pour trois choses :<\/p>\n

    \n
  1. Stocker les ressources li\u00e9es au workflow (flow, metadata, users, …)<\/li>\n
  2. Stocker les donn\u00e9es d’ex\u00e9cution de workflow<\/li>\n
  3. Queue interne pour passage de messages asynchrone entre composants<\/li>\n<\/ol>\n

    La queue interne est la plus sensible des utilisations, elle est au coeur de Kestra et son Executor, responsable de la logique d’orchestration, en est tr\u00e8s d\u00e9pendant.\nL’Executor traite une ex\u00e9cution en boucle, \u00e0 chaque \u00e9tape il va faire avancer le workflow puis envoyer des t\u00e2ches \u00e0 ex\u00e9cuter au worker et un ev\u00e8nement de mise \u00e0 jour de l’ex\u00e9cution pour se re-d\u00e9clencher lui-m\u00eame.\nDonc il lit un message dans la queue, traite le message, et en envoie un autre.\nLa queue JDBC fonctionne via un SELECT ... FOR UPDATE<\/code>, \u00e0 la fin du traitement du message, il est supprim\u00e9 dans la m\u00eame transaction.\nPour optimiser les performances, la queue lit en batch (pollSize<\/code> – 100 par d\u00e9fault) et l’Executor traite en parall\u00e8le sur un nombre de threads configur\u00e9 par d\u00e9faut au nombre de coeurs CPU disponible.<\/p>\n

    Chaque ex\u00e9cution peut induire des dizaines voire des centaines de messages<\/strong> et donc de transactions DB, ce que je suspecte \u00eatre la cause des diff\u00e9rences de performances.<\/p>\n

    Apr\u00e8s avoir v\u00e9rifi\u00e9 que les indexes \u00e9taient identiques entre les deux bases et correctement utilis\u00e9s, j’ai test\u00e9 plusieurs choses:<\/p>\n

      \n
    1. Configuration de la datasource, entre autres activer le cache des prepared statement qui est d\u00e9sactiv\u00e9 par d\u00e9faut en MySQL mais activ\u00e9 en Postgres (voir ici<\/a> pour r\u00e9f\u00e9rence). Aucun changement<\/strong>.<\/li>\n
    2. Augmenter la taille du pollSize<\/code> pour avoir des batch de plus grande taille (250). Aucun changement<\/strong>.<\/li>\n
    3. Baisser la taille du pollSize<\/code>, pour avoir des commits de plus petite taille (10). Pire!<\/strong>.<\/li>\n<\/ol>\n

      J’ai alors demand\u00e9 \u00e0 Claude ce qu’il en pensait et il m’a r\u00e9pondu :<\/p>\n

      \n La valeur par d\u00e9faut de sync_binlog=1<\/code> de MySQL impose un fsync<\/code> synchrone du binlog \u00e0 chaque commits, et la conception de la queue JDBC de Kestra effectue des commits extr\u00eamement fr\u00e9quents (environ 52 commits par ex\u00e9cution, soit environ 2 600 commits\/seconde lors d\u2019un test de performance de 6 minutes avec 18 000 ex\u00e9cutions), car le traitement des messages s\u2019effectue au sein de la m\u00eame transaction que chaque cycle de requ\u00eatage de la file d\u2019attente. Par d\u00e9faut, Postgres effectue un fsync du WAL par commit et ne dispose pas de deuxi\u00e8me journal ; MySQL en effectue deux (redo log + bin log).\n<\/blockquote>\n

      Pour r\u00e9sumer, MySQL est configur\u00e9 par d\u00e9faut pour faire deux fsync (appel syst\u00e8m pour synchroniser sur disque les \u00e9critures de fichiers) par commit alors que Postgres n’en fait qu’un. Le deuxi\u00e8me est li\u00e9 au binlog utilis\u00e9 pour le point-in-time recovery et la r\u00e9plications entre r\u00e9plicas, l\u00e0 o\u00f9 le redo log est propre au moteur de stockage de MySQL (InnoDB ici), le binlog est identique quel qu’il soit.<\/p>\n

      En d\u00e9sactivant le binlog (--skip-log-bin<\/code>) les performances sont \u00e0 parit\u00e9 entre MySQL et Postgres ! :tada:<\/p>\n

      Mais en production, d\u00e9sactiver totalement le binlog n’est pas une bonne id\u00e9e, on peut par contre s\u00e9lectionner ce qui doit \u00eatre stock\u00e9 dans le binlog (via binlog_row_image<\/code>) ou la fr\u00e9quence d’\u00e9criture (via sync_binlog<\/code>).<\/p>\n

      Configurer binlog_row_image<\/code> \u00e0 MINIMAL<\/code> va cr\u00e9er des \u00e9v\u00e8nements plus petits dans le binlog, baissant donc le nombre d’octets \u00e9crit par seconde. Les tests ne se sont pas montr\u00e9s concluants, c’est r\u00e9ellement le nombre d’\u00e9criture qui pose probl\u00e8me, pas leur taille, ce qui est coh\u00e9rent avec les performance moins bonne quand on baisse le pollSize<\/code>.<\/p>\n

      Configurer sync_binlog<\/code> \u00e0 25 va \u00e9crire le binlog sur disque tous les 25 commits au lieu de chaque commit. Le redo log d’InnoDB reste synchronis\u00e9 \u00e0 chaque commit : un crash de MySQL ne fait perdre aucune donn\u00e9e. En cas de crash de l’OS ou de la machine, jusqu’\u00e0 24 commits peuvent manquer dans le binlog (mais pas dans la base), ce qui n’a d’impact que pour la r\u00e9plication et le point-in-time recovery.<\/p>\n

      Les performances sont alors proches de celles de Postgres. C’est un compromis entre performance et durabilit\u00e9 du binlog : \u00e0 vous de choisir la valeur selon votre tol\u00e9rance, mais la configuration du binlog est un classique du tuning MySQL.<\/p>\n

      Pour conclure, j’avais un a priori n\u00e9gatif sur les performances de MySQL mais sachant que certains gros utilisateurs de Kestra (des milliers de flows, des millions d’executions par mois) l’utilisaient je me suis dit qu’il fallait analyser \u00e7a. Et comme je ne suis pas expert, la petite aide de Claude m’a permis de pointer dans la bonne direction et d’en apprendre un peu plus sur le fonctionnement interne de MySQL.<\/p>","protected":false},"excerpt":{"rendered":"

      Kestra supporte entre autre Posstgres et MySQL comme base de donn\u00e9es, nos benchmarks internes montraient que Postgres \u00e9tait beaucoup plus performant que MySQL pour faire tourner Kestra. Nous conseillons donc g\u00e9n\u00e9ralement de faire fonctionner Kestra en production avec Postgres. Lors de nos benchmarks, Postgres support 4000 executions\/mn avec une latence de 370ms pour nos flow type, avec une latence autour de 130ms pour un lancement unique. MySQL de son c\u00f4t\u00e9 n’arrive m\u00eame pas \u00e0 soutenir 1000 executions\/mn et a une…

      Lire la suite Lire la suite<\/span><\/a><\/p><\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"activitypub_content_warning":"","activitypub_content_visibility":"","activitypub_max_image_attachments":4,"activitypub_interaction_policy_quote":"anyone","activitypub_status":"federated","footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false,"_members_access_role":[],"_members_access_error":""},"categories":[9],"tags":[203,211,236,159],"class_list":["post-2196","post","type-post","status-publish","format-standard","hentry","category-informatique","tag-database","tag-kestra","tag-mysql","tag-performance"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t