One issue I see is the cost of constantly opening and closing a TCP connection for something like the postgres example. Postgres specifically has quite a high cost for each connection. Pgbouncer helps, but this could still be pretty consequential at the concurrency that workers can offer.
Maybe in the future we could create local pools that can be shared across executions, similar to how AWS Lambda does it now?
I haven’t personally tried this but it might be somewhat possible today. Have you tried creating a worker that’s responsible for maintaining a pool of DB connections, turning on smart placement for it, and then using service bindings to talk to it to do the queries? That should work in terms of causing your pooler worker to be placed closed to your DB although not 100% clear on whether that will be sufficient to pool correctly. Worth an experiment. Using a DO is the other option provided your careful to make sure the DO actor is instantiated in a geographic region next to the database.
I don’t think you can connect() to the service binding yet which limits the flexibility as you have to manually tunnel your queries through a fetch handler, but it should be fairly doable and probably possible to have a generic conversion shim layer to convert.
3 comments
[ 3.7 ms ] story [ 11.8 ms ] threadOne issue I see is the cost of constantly opening and closing a TCP connection for something like the postgres example. Postgres specifically has quite a high cost for each connection. Pgbouncer helps, but this could still be pretty consequential at the concurrency that workers can offer.
Maybe in the future we could create local pools that can be shared across executions, similar to how AWS Lambda does it now?
I don’t think you can connect() to the service binding yet which limits the flexibility as you have to manually tunnel your queries through a fetch handler, but it should be fairly doable and probably possible to have a generic conversion shim layer to convert.