How exactly does pooling work with supavisor
- Is this a correct way to understand how Supavisor works? If supavisor is handling a
default_max_clientsize of 1000, what happens when a request for the 1001st connection comes in? Does it get rejected? Or will it be queued to connect? If so for how long? - Based on https://supabase.com/blog/supavisor-postgres-connection-pooler, if i use serverless functions ONLY in vercel, and i use supavisor with a small sized database, i get 1000 max clients, and 90 max connections. If I have session mode, each serverless function would take up 1/1000 clients for the entirety of its lifetime (once it is invoked until it goes back to a cold state, but does not require connecting more than once for multiple queries in the same function). If i have transaction mode set in my pool settings, does that mean that i effectively have 1000 concurrent queries in my pool? Normally, vercel functions stay alive for a while after they are invoked and maintain the database connection (wasting the connection until the function is invoked or the function goes back to a cold state). With the described settings, the moment the query finishes executing and returns data to my client (using prisma), would i no longer be using one of the 1000 connections? in other words if i have a serverless function with 2 database queries, is it correct that one invocation from a user would be 1/1000 connections used during the first query, the connection drops (0/1000 connections), then it create a new connection (1/1000) for the second query. so in theory, if a serverless function was invoked 1000 times at the exact same time and the functions ran perfectly in sync, i could have 1000 concurrent invocations of the same serverless function, and during that execution, i would be at 1000/1000 connections during the first database query, 0/1000 in between the queries, then 1000/1000 during the second query, and finally back to 0/1000 the moment the second query finishes. is this a correct understanding of things?
