I'm new to Azure and built a small web app mainly as a learning project. Because the free tier kept pausing, I switched to a paid Azure SQL serverless configuration with low-spec hardware and disabled auto-pause. The app received almost no traffic, but my monthly credits were exhausted in about two weeks, resulting in roughly $420 per month in estimated costs.
The database settings were General Purpose, Serverless, Standard-series Gen5 hardware, a maximum of 4 vCores, a minimum of 1 vCore, 32 GB of storage, no zone redundancy, and locally redundant backups. The metrics showed about 2.4K vCore-seconds billed per hour. Azure's pricing calculator suggested the same setup should cost less than $10 per month, so I'm trying to understand whether this bill is expected and what a more suitable low-cost configuration would be.
4 Answers
The minimum vCore setting matters here. With auto-pause disabled and the minimum set to 1 vCore, the database continues billing while it is running, even when the application is idle. The 4-vCore maximum can also become expensive if the workload scales up. For a tiny app, 4 vCores is probably much more capacity than you need.
First verify the charge in the subscription’s Cost Analysis and billing reports so you know the database is actually responsible for the full amount. If it is, compare the exact region, compute tier, vCore usage, storage, backup, and other line items against the pricing calculator. A small difference in configuration or billing assumptions can make the estimate look very different.
For a small, lightly used SQL database, a DTU-based Basic or Standard tier may be cheaper and simpler than serverless. A Basic 5-DTU database is often enough for light workloads, although large imports and heavy queries will take longer. If you need serverless scaling, keep the minimum vCores low and enable auto-pause when the application can tolerate waking up after inactivity.
Cloud resources generally cost money simply by being provisioned, regardless of whether they are doing useful work at that moment. Start with the smallest practical configuration and increase it only when measurements show you need more capacity. If you use PostgreSQL instead, a burstable compute option can also be a more economical choice for an occasional-use application.
The database pricing page should also show an estimate while you select the compute and storage options. That can help identify whether the calculator was using different settings.