I recently deployed a very small inventory and sales application and am trying to keep the infrastructure affordable. The frontend runs on object storage and a CDN, while the .NET API runs on a small virtual machine or application platform. The database is SQL Server Express on an RDS db.t3.micro with 20 GB of gp2 storage and very little traffic.
After about 20 days, the database portion cost roughly $55: around $43 was for T3 CPU credits, $10 for instance usage, and $1.50 for storage. CPU utilization stayed near 42–45%, the CPU credit balance remained at zero, and surplus credits continued accumulating. However, database load was only about 0.04 AAS, individual queries were below 0.01 AAS, and there were almost no connections. Free memory was usually around 50–100 MB. The highest reported activity appeared to come from the database administration service under the system account rather than from my application.
At this rate, this tiny database could cost $80–90 per month, which is far beyond what I expected. I am considering moving to a larger instance, installing SQL Server Express on the same machine as the API, or migrating to PostgreSQL, MySQL, or possibly a NoSQL database.
I would prefer to keep the whole setup near $10–25 per month, but I also do not want to take on a database administration burden that I cannot reliably handle. Backups, restore testing, patching, monitoring, storage management, security, and disaster recovery are all concerns.
Is this CPU behavior expected for SQL Server Express on a db.t3.micro? What would be the safest and most cost-effective approach for such a small production workload?
4 Answers
Also check whether query-level database monitoring or insights is enabled. Collecting detailed performance data can consume some resources, so disabling unnecessary diagnostics may reduce overhead. It probably will not explain all of the surplus-credit charges if CPU has been continuously high, but it is an easy thing to test.
I would first identify the background process responsible, then compare the monthly cost of a non-burstable or appropriately sized instance against a PostgreSQL migration. Do not assume that moving the database to the application server is free: you would be exchanging service charges for operational work and recovery risk.
The simplest cost reduction is probably moving away from SQL Server. PostgreSQL or MySQL are lighter and avoid the SQL Server licensing cost, and a .NET API using Dapper usually does not require a complete rewrite. There will still be some SQL and schema changes, so test compatibility carefully, but this is likely a smaller change than redesigning the application around DynamoDB.
A low-cost hosted PostgreSQL provider may fit the budget better than a continuously running RDS instance. Make sure the chosen plan includes automated backups, retention, and a practical restore process before treating it as production-ready.
DynamoDB can be extremely inexpensive for a tiny workload, and on-demand pricing may cost almost nothing. However, it requires designing around access patterns, partition keys, and denormalized data. For an existing CRUD application with relational tables, it could mean a substantial rewrite, so the lower bill may not justify the development time.
Exactly. A key-value or document database is worth considering for a new application, but migrating an existing relational API just to save a small monthly amount can create more complexity than it removes.
The application workload may not be the main issue. A t3.micro is burstable, and once it continuously exceeds its baseline CPU allocation, surplus credits are billed. If the database itself sits around 40–45% CPU while query load is almost nonexistent, the instance type and SQL Server overhead are probably a poor match.
A t3.small would provide more memory and CPU baseline, but it still uses the same burst-credit model. I would not move SQL Server onto the application machine solely to save a few dozen dollars unless you are prepared to own backups, restores, patching, monitoring, disk failures, and recovery. Managed hosting reduces that operational risk even though it does not eliminate every responsibility.
Before scaling up, I would verify what is consuming the CPU. SQL Server Express may simply be too heavy for a 1 GB burstable instance, but database insights and administration tasks can also add overhead. If the workload is genuinely idle, switching database engines may be more effective than buying a larger burstable instance.
That is the direction I am leaning. The API is already built with .NET and Dapper, so PostgreSQL seems more realistic than redesigning everything for NoSQL. I mainly want to avoid replacing one low-cost option with a service that has weak backup or recovery guarantees.