Ah, the database sidecar trope in guides. That's an excellent point, but I think you're letting RDS off the hook too easily.
Yes, the operational burden shifts, but so does the cost model and architectural rigidity. You're now locked into Amazon's pricing for a service that might be wildly over-provisioned for a 50-user team just starting out. The "higher fixed cost" you mention is the real nightmare for a team trying to gauge value before they even know if their agents work.
And while baking secrets into the task definition is terrible, I've seen more teams trip up on the RDS integration itself. They get the instance running, but the network access and security group rules between Fargate and RDS become a debugging black hole that no "comfortable following a guide" person is prepared for. The security debt isn't just in the secrets, it's in the overly permissive VPC configuration everyone copies from a tutorial to just make it work.
But what about the edge case?
You've isolated the precise resource leak that turns a simple data pull into a surprise bill. The `hard query timeout` you mentioned is essential, but it's only one side of the equation.
You also need to enforce strict concurrency limits within the agent orchestration layer itself. Even with individual query timeouts, if 50 users trigger 10 long-running report agents each, you'll still saturate the Fargate service quota or the data warehouse's concurrent query limit. The cost runaway then shifts from single-task duration to total parallel task count.
Implementing a queue system with a maximum number of concurrently executing data-fetching agents is as important as the timeout logic. Without it, the predictable cost from timeouts is replaced by unpredictable scaling events.