Depuis plusieurs années, PostgreSQL est l’un des systèmes de bases de données les plus critiques alimentant ChatGPT et l’API d’OpenAI. Dans un article consacré à l’usage de sa solution open source dans un contexte de forte croissance du nombre d’utilisateurs, la société précise qu’ « au cours de l’année écoulée, la charge sur PostgreSQL a été multipliée par plus de 10 et continue de croître rapidement ». Les équipes du fournisseur ont constaté que ce SGBDR (initialement crée par une équipe de chercheurs de l’Université de Berkeley) a pu être mis à l’échelle avec « une seule instance Azure PosgreSQL principale  et près de 50 réplicas de lecture répartis dans plusieurs régions du monde ». Une évolution qui a nécessité des optimisations rigoureuses et une ingénierie solide.

Dans son document, OpenAI reconnait qu’il peut apparaître surprenant qu’une architecture à un seul nœud primaire puisse répondre à ses exigences. Il avoue que la mise en œuvre est loin d’être facile avec l’apparition de plusieurs incidents causés par une surcharge de la base de données. Ces problèmes sont liés à l’implémentation du contrôle d’accès concurrent (MVCC) de PostgreSQL, qui le rend moins efficace pour les charges de travail à forte intensité d'écriture. Par ailleurs, MVCC engendre des défis supplémentaires comme la prolifération des tables et des index, une augmentation de la charge de maintenance des index et un paramétrage complexe du nettoyage automatique (auto-vacuum). Par exemple, l'éditeur a observé « une requête extrêmement coûteuse qui joignait 12 tables, et les pics de cette requête étaient responsables de plusieurs incidents critiques (SEV) de haute gravité. »

Une répartition et des optimisations

Pour atténuer ses difficultés, la société a migré certaines charges de travail partitionnables à forte intensité d’écriture vers de systèmes comme Azure Cosmos DB. Il indique « nous n'autorisons plus non plus l'ajout de nouvelles tables au déploiement PostgreSQL actuel. Les nouvelles charges de travail sont par défaut réparties sur les systèmes partitionnés ». Elles sont distribuées sur plusieurs régions avec des garanties de haute disponibilité. Par ailleurs, en cas de pics soudains, la société isole les workloads sur des instances dédiées pour garantir que les pics soudains de requêtes gourmandes en ressources n'impactent pas le reste du trafic. De même, elle a mis en place PgBouncer, un outil pour optimiser les connexions communes à la base de données. Outre le fait de réduire le nombre de connexions, il améliore la latence de ces dernières, passant de 50 ms à 5 ms.

Une évolution mais pas une révolution. En effet, le fournisseur reste attaché à son instance principale non partitionnée pour gérer toutes les écritures. Il explique ce choix par le fait que le partitionnement des workloads applicatifs existants serait extrêmement complexe et chronophage « nécessitant des modifications sur des centaines de points de terminaison et pouvant prendre des mois, voire des années ». L’équipe préfère apporter des optimisations sur une architecture qui « offre une marge de manœuvre suffisante pour supporter la croissance continue du trafic ». Tout en laissant la porte ouverte au partitionnement de PostgreSQL à l’avenir.