Le problème N+1
Le problème N+1, c'est une page qui pose une question à la base de données pour obtenir une liste, puis une question de plus pour chaque ligne de cette liste. Cent commandes affichées avec le nom du client : une requête pour les commandes, cent pour les clients, cent une au total. En local, sur dix lignes de test, rien ne se voit. En production, le nombre de requêtes grandit avec les données, et la page ralentit sans qu'une ligne de code ait changé. La correction consiste à demander la liste et ce qui s'y rattache en une seule fois. Avec Supabase, une sélection imbriquée ramène les commandes et leur client dans la même requête ; avec Prisma, `include` ou la stratégie de chargement `join` font le même travail. Le piège guette le code généré : une boucle qui interroge la base à chaque tour est lisible et marche sur les données de test, donc rien n'alerte ni l'agent ni toi. Le problème a un voisin qui tue aussi en silence : ouvrir une connexion neuve à chaque requête. PostgreSQL accepte en général une centaine de connexions simultanées par défaut, et refuse au-delà. Un pool garde un petit nombre de connexions ouvertes et les partage entre tous les utilisateurs. La règle de départ publiée par l'équipe de HikariCP, un pool de connexions Java, est de deux fois le nombre de cœurs du serveur plus le nombre de disques, soit 9 pour quatre cœurs et un disque. Sur Supabase, les fonctions serverless passent par le pooler en mode transaction, sur le port 6543.