I'm testing a mobile app that isn't deployed yet, and I'm currently the only user. When I open it for the first time after the database has been inactive for roughly a day, the app sometimes reports a connection timeout. Since the database uses a serverless tier, I assume it has been paused and needs time to start again. Is there a way to periodically wake it up or otherwise reduce the initial delay without significantly increasing my Azure bill?
4 Answers
A scheduled health check could periodically connect to the database and run a lightweight query. However, that only prevents or delays the pause; it doesn’t remove the cost. You could also add connection retry logic so the app waits and tries again when the database is waking up.
You can run a query every few hours or disable the automatic pause feature, but keeping the database active means you’ll be billed for compute instead of benefiting from serverless pausing.
The cold start is the tradeoff for serverless pricing. If you keep the database warm continuously, you’ll use up any free compute allowance quickly and may pay more. For a small always-on database, a low-tier provisioned or DTU-based plan may be a better option. The cheapest tier is less powerful and has limited storage, but it avoids cold starts and can cost only a few dollars per month.
If you need relational SQL without startup delays, moving to a small provisioned tier is probably the simplest solution. For workloads that don’t require SQL, lower-cost options such as a free NoSQL tier or inexpensive key-value storage may also work, but they would require changing the application’s data model.
That makes sense. I’ll compare the small provisioned tiers with the current serverless setup and see whether the predictable monthly cost is worth avoiding the timeout.