I recently deployed a small inventory and sales application with an Angular frontend hosted on object storage and a CDN, plus a .NET API running on a small compute instance. The database is SQL Server Express on a 20 GB gp2 RDS db.t3.micro instance. Traffic and transaction volume are extremely low, but the database has cost about $55 in roughly 20 days. More than $43 of that came from surplus CPU credits, while the instance itself cost about $10 and storage about $1.50.
CloudWatch shows CPU utilization around 42–45% almost continuously, a CPU credit balance of zero, and surplus credits accumulating. There are almost no active connections, freeable memory is only around 50–100 MB, and database load is approximately 0.04 AAS. The top activity appears to come from the managed database service under the system account rather than from my application.
I need to keep this production application reliable while ideally spending around $10–25 per month. I am considering moving to a larger or non-burstable database instance, migrating from SQL Server to PostgreSQL or MySQL, using a serverless database, or moving SQL Server onto the application server. The last option worries me because I am a developer rather than a DBA, and I do not want to become solely responsible for backups, restore testing, patching, monitoring, storage, and disaster recovery.
Is this level of CPU usage normal for SQL Server Express on a db.t3.micro, or does it indicate a configuration or application problem? What would be the safest and most economical approach for this workload?
3 Answers
A db.t3.micro is a burstable instance, so continuous CPU usage can exhaust its baseline credits and create surplus-credit charges even when the application has very little traffic. However, 40–45% CPU with almost no database load is worth investigating rather than simply accepting. Check whether performance monitoring or query-level insights are adding overhead, review SQL Server and RDS logs, and confirm that the application is not repeatedly opening connections or running background queries. Moving to a t3.small may provide more memory and CPU headroom, but it still uses the same burst-credit model, so it may only reduce the symptom rather than eliminate it.
The most practical long-term option is probably migrating from SQL Server Express to PostgreSQL or MySQL. They avoid the SQL Server licensing cost and are often lighter on a small instance. With a .NET API using Dapper, the migration may be manageable if the application mainly uses ordinary tables, queries, and stored procedures, although SQL syntax and procedure code still need testing. Keep the existing schema and run both databases during a short migration if reliability matters.
DynamoDB can be extremely inexpensive for tiny workloads, and serverless PostgreSQL offerings may stay within a free or very low-cost tier, but both require checking limits, sleeping or scaling behavior, backups, and production durability. DynamoDB would usually require a much larger redesign because its data modeling and query patterns differ from relational SQL.
A relational PostgreSQL-compatible service is likely a smoother transition than DynamoDB for an inventory and sales API. Do not choose NoSQL solely because the bill looks attractive if it forces a complete rewrite of the data model.
I would avoid moving SQL Server onto the application server just to save a few dozen dollars. That can work for a disposable internal tool, but for a production application it makes you responsible for backups, restore procedures, patching, disk failures, monitoring, security, and recovery. A managed database is valuable precisely because it reduces that operational burden, even though it does not remove the need to configure backups and test recovery yourself.
If the application is not revenue-generating, reducing maintenance may be more important than minimizing the absolute monthly bill. A slightly larger managed instance or a cheaper managed PostgreSQL service could be a better trade than self-hosting SQL Server.
Low application load by itself does not prove the database should use almost no CPU. SQL Server Express has a relatively heavy baseline footprint for a very small instance, and one gigabyte of memory leaves little room for the operating system and monitoring tools. PostgreSQL or MySQL may fit this instance more comfortably, but the actual cause should still be checked first.