We're curious if RT connects to the DB for each tab I have open or has one connection open on the backend for all our apps?
Retool will create new connections for each instance of an app that is open, so if you the app open many times (or if many users have the same app opened), then this scenario would lead to many connections being opened. We do pool connections in some cases, but depending on the resource type and how it gets routed in our backend, one user could have several connections open. All these users will be connected to your database using the same DB user that is setup in your Retool account. Are these multiple connections causing issues for you?
I'm currently running into issues with multiple connections. Aside from new connections for each instance of an app open... does Retool also create new connections for each resource query that is part of an app?
If so, what would be the best way to run multiple queries in succession without creating multiple connections?
Hi @bernardmma !
Due to our backend routing, it is possible that requests could be potentially sent from a different connection or connection pool. If you're trying to keep the connections to an absolute minimum, I'd recommend putting a connection pooler in front of your database so that you can manage and limit the connections. PgBouncer for Postgres is an example of this!
Mine retool app is creating a new connection every time when we run the query(PostgreSQL). As a result, I am facing too many connection for the role error. Retool also not releasing the idle connection as well.
I couldn't find any settings in the resource.
Can yo help me to sort out the issue?
I am running into the same issue of too many connections on simple submissions of only 50 records or so and I am the only one using the app.
This makes Retool a rather useless app if some extremely lowkey data handling requires some advanced changes on the DB itself. Wasn't the purpose of Retool to not have to do that kind of stuff???
It also maxes out connections when running a Promises trigger on an update record. e.g. say you can't perform a bulk update (because of a composite primary key) and need to do it row by row. If your table has more then 100 rows, or even if you run it multiple times on one table, it quickly saturates the 100 connections allowed by GCP. This is a problem.
1 Like
Has there been any new development on this? I am also running into the problem of every tab in my retool app running out of available connections. I'm using a cloud based database so I do not have the option of installing a connection pooler, and I also have no idea what level of service I would need from the database host because I have no way of knowing how many connections retool is creating. Do I need 10 concurrent connections? 20? 500? All I can tell for sure is it's more than 5.
Hi all!
We are currently tracking this issue, but we don't have an update or timeline on when an improvement will be shipped.
This previous message is still true!
Retool will create new connections for each instance of an app that is open, so if you the app open many times (or if many users have the same app opened), then this scenario would lead to many connections being opened. We do pool connections in some cases, but depending on the resource type and how it gets routed in our backend, one user could have several connections open. All these users will be connected to your database using the same DB user that is set up in your Retool account.
Due to the scale of our deployment, during periods of high request volume to your resource (like having many users accessing the same application, or having an application that runs many queries simultaneously to the same resource), several connections will be made to your database. In these high-volume scenarios, the upper bound of connections will be < 300.
If you're not able to configure the number of connections made to your database using a connection pooler, you may also be able to utilize Query Caching in order to reduce the number of connections. Another option would be to use Self Hosted Retool, where the smaller infrastructure would make fewer connections to your database.
@ben we self-host retool and have a small pool of users (around 60), our RDS instance can take up to 900 simultaneous connections, in one month retool created (and never dropped!) almost 700 connections... restart the instance, drop connections, we're good again, but this is insane, why wouldnt it drop database connections?
I know I am answering on a post that is more than an year old, is this behaviour still true?
I could put a pooler in front of it but I shouldnt need to add one more thing to manage to solve this.
1 Like