65 articles on database — what drives the cost, how it is priced, and where the savings actually are.
Azure SQL Database serverless bills compute per second and pauses when idle, which can slash the bill for intermittent workloads but cost more for steady ones. Here is where serverless wins and where provisioned vCore is cheaper.
Azure SQL elastic pools let many databases share a single pool of DTUs or vCores, which is far cheaper than provisioning each database on its own when their peaks do not coincide. Here is how the math works.
Cosmos DB autoscale raises the per-RU/s rate by 50 percent but scales throughput automatically between 10 percent and 100 percent of a maximum. For variable traffic it can be cheaper than standard provisioned; for flat traffic it is a needless premium. Here is the math.
Running Postgres or MySQL yourself on EC2 is cheaper per hour than RDS, but RDS handles backups, failover, and patching. The premium is real, and so is the operational burden it removes. Here is when self-hosting a database pays off, with numbers.
Serverless databases scale capacity automatically and bill per use, costing nothing when idle; provisioned databases reserve fixed capacity at a flat rate. The crossover is utilization, and it decides which is cheaper. Here is the math with numbers.
ElastiCache (Redis and Memcached) is priced per node by instance type, so node sizing and count drive the bill. Oversized memory, too many replicas, and the wrong node family are the common overspends. Here is how to size for cost.
RDS Multi-AZ roughly doubles instance and storage cost by running a standby in a second Availability Zone for automatic failover. Here is what you actually pay for, and when the availability is worth the premium.
Each RDS read replica is a full additional instance with its own compute and storage cost, plus data transfer for cross-region replicas. Here is how read replica pricing works and how to scale reads without overpaying.
RDS instances are often provisioned larger than the workload needs, and unlike stateless compute, resizing a database takes care. Here is how to right-size RDS instance class, storage, and IOPS to real usage without risking the database.
Aurora Serverless v2 scales database capacity in fine-grained Aurora Capacity Units and bills per ACU-hour. It can save money on variable workloads but cost more on steady ones. Here is how the pricing works and when to use it.
Managed Redis (ElastiCache, Memorystore, Azure Cache) bills mostly for the node size and count you run, per hour, plus data transfer and optional replicas. Here is how Redis pricing works and how to size it without overpaying.
Connection pooling lets a database serve more clients with fewer resources, so you can run a smaller, cheaper instance. The cost impact comes from avoiding over-provisioning driven by connection limits. Here is how pooling saves money.
Amazon DocumentDB bills for instance hours, storage consumed, I/O operations, and backups, with a separate compute-and-storage model. Understanding each meter, and how I/O can dominate, is key to controlling DocumentDB cost. Here is the breakdown.
DynamoDB cost hinges on capacity mode: on-demand bills per request with no planning, provisioned bills for reserved throughput you must size. Picking the right mode, and sizing provisioned capacity, is the core cost decision. Here is how.
The right index turns a full scan into a fast lookup, cutting both query latency and the compute or I/O you pay for. But every index adds write overhead and storage. Here is how indexing trades cost against performance and how to get it right.
Databases are often the biggest single line on the bill and the most over-provisioned, sized for a peak that rarely comes or copied from another environment. Right-sizing to real CPU, memory, and IO need cuts cost without hurting performance. Here is how.
Partitioning splits a large table into segments by a key (often date), so queries with a matching filter scan only relevant partitions instead of the whole table. On per-scan and IO-billed systems, that directly cuts cost. Here is the tradeoff.
When a single database cannot handle the write load, sharding splits data across nodes to scale horizontally. It adds infrastructure and significant operational complexity, so it is a last resort after cheaper scaling. Here is the cost tradeoff.
A materialized view precomputes an expensive query and stores the result, so reads are fast and cheap, at the cost of storage and refresh compute. For frequently-run expensive queries, the trade pays off. Here is the cost math.
DynamoDB, Firestore, and Cosmos DB price NoSQL differently, DynamoDB per capacity or request, Firestore per operation, Cosmos per request unit or serverless. The cheapest depends on read/write mix and traffic shape. This compares the models.
AWS RDS, GCP Cloud SQL, and Azure Database for PostgreSQL Flexible Server price managed Postgres similarly, compute per vCPU and memory, storage, and high-availability options. The cost drivers and levers are shared. This compares them.
Keyspaces (managed Cassandra) bills read and write request units, storage per GB-month, and optional features, with on-demand and provisioned capacity modes. It scales to zero with no clusters to manage. Here is how it prices versus self-managed Cassandra.
Global tables replicate a DynamoDB table across regions, so you pay replicated write capacity, storage in every region, and cross-region replication transfer. The multiplier is the number of regions. Here is when multi-region is worth it.
Cloud SQL now has two editions: Enterprise and Enterprise Plus. Enterprise Plus costs more per vCPU and memory but adds a data cache, better performance, and near-zero-downtime maintenance. Here is how the editions price and when the upgrade pays off.