Le problème N+1
The N+1 problem is a page that asks the database once for a list, then once more for every row in that list. A hundred orders shown with the customer's name: one query for the orders, a hundred for the customers, a hundred and one in total. Locally, on ten test rows, nothing shows. In production the query count grows with the data, and the page slows down without a single line of code changing. The fix is to ask for the list and what belongs to it in one go. With Supabase, a nested select brings back the orders and their customer in the same request; with Prisma, `include` or the `join` load strategy does the same job. Generated code walks straight into it: a loop that queries the database on every pass reads clearly and works on test data, so nothing warns the agent or you. The problem has a neighbour that also kills quietly: opening a fresh connection for every request. PostgreSQL typically accepts around a hundred simultaneous connections by default and refuses beyond that. A pool keeps a small number of connections open and shares them across every user. The starting rule published by the HikariCP team, a Java connection pool, is twice the server's core count plus the number of disks, so 9 for four cores and one disk. On Supabase, serverless functions go through the pooler in transaction mode, on port 6543.