cost vs performance
29 articles on cost vs performance — what drives the cost, how it is priced, and where the savings actually are.
Database indexing: the cost-performance trade you control with SQL
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.
Right-sizing databases: matching the instance to the load
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.
Multi-region: the cost of low latency everywhere
Running in multiple regions cuts latency for distributed users and adds resilience, but it multiplies compute, replicates data, and adds cross-region transfer. Knowing when the latency and availability are worth the multiplied cost is the decision. Here is the framework.
GPU instance cost optimization: the most expensive hour to waste
GPU instances cost many times a CPU instance per hour, so idle GPUs, oversized accelerators, and full-price on-demand are expensive mistakes. Spot, right-sizing, and sharing are the big levers. Here is how to keep GPU cost under control.
VPN vs Transit Gateway cost: connecting networks at scale
Site-to-site VPN bills per connection-hour plus data; Transit Gateway bills per attachment-hour plus data processing but scales to many networks cleanly. For a few connections VPN is cheaper; for many, Transit Gateway wins. Here is the tradeoff.
Global Accelerator cost: premium routing for global users
AWS Global Accelerator bills a fixed hourly fee plus a premium per-GB data transfer charge, routing user traffic over the AWS backbone for better performance. For latency-sensitive global apps it helps, but the premium adds up. Here is the model.
ETL vs ELT cost: where you transform changes the bill
ETL transforms data on separate compute before loading it; ELT loads raw data into the warehouse and transforms there using warehouse compute. Which is cheaper depends on your warehouse pricing and transformation load. Here is the tradeoff.
Streaming vs batch data processing: the cost of freshness
Streaming processes data continuously for low-latency freshness, keeping compute always running; batch processes in scheduled bulk runs on transient compute. When data does not need to be fresh instantly, batch is far cheaper. Here is the tradeoff.
GPU vs CPU for inference: which is cheaper to serve on
GPUs accelerate inference but cost far more per hour; CPUs are cheaper but slower per request. For small models, low throughput, or latency-tolerant workloads, CPU is often cheaper per inference. Here is how to decide.
Batch vs real-time inference: the cost of immediacy
Real-time inference keeps serving capacity always ready to respond instantly; batch inference processes predictions in bulk on transient compute. When predictions can wait, batch is far cheaper. Here is the tradeoff.
Multi-region cost tradeoff: what high availability really costs
Running across regions buys resilience and lower latency for distributed users, but roughly multiplies infrastructure cost and adds cross-region data transfer. The tradeoff is availability and latency versus cost. Here is how to weigh it.
WebSockets vs polling: the cost of real-time updates
Polling for updates repeatedly hits your backend whether or not anything changed; WebSockets push updates over a persistent connection only when they occur. For frequent updates to many clients, the cost tradeoff is nuanced. Here it is.
Async processing: how queues and workers cut cost under load
Processing work synchronously means provisioning compute for peak request rate; processing it asynchronously via a queue lets workers drain at their own pace, so you provision for average, not peak. This decouples cost from spikes. Here is the tradeoff.
Database partitioning: cutting query cost by scanning less
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.
Rate limiting: protecting your backend from expensive traffic
Rate limiting caps how many requests a client can make, protecting your backend from abuse, runaway clients, and traffic spikes that would drive up compute and downstream cost. It is a cheap control that prevents expensive incidents. Here is the case.
gRPC vs REST: the cost of the bytes on the wire
gRPC's binary encoding and HTTP/2 multiplexing send fewer bytes and use connections more efficiently than JSON over HTTP/1.1, which can cut egress and compute at high volume. But REST is simpler and universal. Here is the cost tradeoff.
Cold start mitigation cost: paying to keep functions warm
Serverless cold starts add latency; mitigating them with provisioned concurrency or minimum instances means paying for warm capacity around the clock. Whether that trade is worth it depends on traffic and latency needs. Here is the cost math.
Database sharding: the cost of scaling writes beyond one node
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.
Materialized views: trading storage and refresh for query savings
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.
Event-driven vs polling: the cost of asking versus being told
Polling burns compute and requests asking for changes that usually have not happened; event-driven architectures do work only when something occurs. For infrequent events, event-driven is dramatically cheaper. Here is the cost tradeoff.
Read replicas: the cost-versus-performance math
A read replica adds a full instance cost to offload reads and improve read latency, but it does not help writes and adds replication lag. Knowing when a replica pays off, versus caching or a bigger primary, is the decision. Here is the framework.
Connection pooling: cheap capacity you are probably wasting
Every database connection consumes memory on the server, so without pooling you scale the database up just to hold connections. A pooler like PgBouncer or RDS Proxy lets a small database serve many clients. Here is the cost-performance case.
Spot instances and performance risk: cheap capacity, with a catch
Spot instances cost up to 90% less but can be reclaimed with little warning, so the saving comes with an interruption risk. Matching Spot to fault-tolerant work, and blending with on-demand, is how you get the discount without the outage. Here is how.
P95 latency cost optimization: cutting spend without missing the tail
Average latency hides the tail that users feel and SLOs measure. Optimizing cost against p95, not the mean, is what keeps a cheaper configuration from quietly breaking. Here is how to reason about the p95-versus-cost frontier.