Retool Database (hosted) is crash-restarting repeatedly — production apps failing
Since at least 13:45 UTC on 10/29, our Retool-hosted Postgres database has been restarting over and over. Queries across many apps fail intermittently with:
server login has been failing, cached error: the database system is in recovery mode (server_login_retry)
server login has been failing, cached error: partial pkt in login phase (server_login_retry)
server conn crashed?
What we've checked
SELECT pg_postmaster_start_time() at ~18:43 UTC showed a last restart at 18:41 UTC, up only ~1.5 minutes, so Postgres itself is restarting, not just connections dropping.
Settings: shared_buffers = 128 MB, work_mem = 4 MB, maintenance_work_mem = 64 MB, max_connections = 112 (about 21 open at the time).
No long-running queries between crashes (pg_stat_activity).
Our scheduled workflows complete successfully, and their timing doesn't line up with the restarts.
Storage is about half of our allowance, so we don't think it's the storage limit.
Questions
Has anyone else seen Retool Database crash-looping like this? Is there a known incident?
Our guess is the instance is running out of memory (128 MB shared_buffers looks small) under a few large tables (~1–3 GB with indexes). Is there a way to see crash logs or memory usage for a Retool-hosted database, or to get a larger instance?
Anything we should change on our side to keep it stable in the meantime?
Can a Retool team member take a look? We can share instance details privately.
A Retool Cloud user's hosted Retool Database (Postgres) has been crash-restarting repeatedly since ~13:45 UTC on 10/29, causing intermittent 'database system is in recovery mode' / 'partial pkt in login phase' query failures; they suspect memory exhaustion against a few large (1–3 GB) tables and want crash/memory visibility, a possible larger instance, and confirmation of any known incident.
AI Response
Retool Database on Cloud is a managed service that stores the equivalent of 5GB of Postgres data, and its underlying compute/memory parameters (shared_buffers, work_mem, etc.) are not customer-configurable or exposed for direct crash-log access. Per the documentation, when storage or capacity limits are being approached or exceeded, the supported path is to reach out to Retool directly to request a limit increase rather than tuning the instance yourself. In the interim, reducing memory pressure on the large tables can help stability — for example, vacuuming/reindexing bloated tables, narrowing wide SELECTs, adding indexes to avoid large sequential scans, and avoiding concurrent heavy writes/large bulk operations. Note that at this capacity the native Retool Database may be undersized for multi-GB production workloads, so an external dedicated Postgres resource is worth considering for workloads of this size.
Sources
Retool Database usage and limits | Retool Docs
Documents the 5GB Retool Database capacity for Cloud orgs and confirms the supported path is to reach out to Retool to request a limit increase, directly addressing the sizing/larger-instance question. RetoolDB Limits
A solved thread on hitting Retool Database limits that corroborates this class of capacity-related issue and outlines the guidance for addressing it.
The Community Team is testing out a new automation. Let us know if it's helpful (or not) by leaving a , , or . Or by marking this post as the "Solution"! Let us know if you have any feedback here.
Thanks for flagging this down. We received your breakage report as well and will look into this with more detail there.
In the meantime, I’ll address your questions based on the information you provided:
There’s no current incidents that have been reported on our side for Retool database.
I see you are using Retool DB as your backed DB. When it comes to Retool Database, it is not designed to be a highly-available, scalable database service and we recommend using a separate managed database provider.
We can address more in depth questions on the breakage report you submitted but if you have any other questions, do let us know.
, 
, or 
. Or by marking this post as the "Solution"! Let us know if you have any feedback 