Database type, capacity, and cache economics

Database economics begins with access semantics. Relational joins, constraints, and multi-row transactions point toward RDS or Aurora when a managed relational engine fits. Predictable key-based access to key-value or document items can fit DynamoDB, but a schema rewrite and hot-key risk are real costs. Amazon Redshift is a columnar warehouse for analytical workloads; it belongs where large scans, aggregation, modeled data, and BI concurrency dominate rather than row-by-row transactions. Amazon Timestream is purpose-built for time-series data and queries organized around time, retention, and recent-versus-historical access. Graph, search, wide-column, and in-memory stores should be chosen only when their access model produces enough benefit to pay for migration, operations, and possible duplication of a system of record. A purpose-built label is not permission to fragment data automatically. State consistency, query shapes, write rate, retention, index needs, and ownership before choosing a service. The generic relational database remains valid when specialized semantics are weak and application simplicity dominates.

After the model is valid, map demand shape to capacity. DynamoDB on-demand is useful for new or unpredictable request traffic, while provisioned capacity with autoscaling can become economical after a stable baseline is measured. Neither mode repairs a poor partition key, scans, oversized items, or excessive indexes. RDS and Aurora require instance or capacity-range, storage, I/O, replicas, backup, and license analysis under the current engine and deployment. A warehouse can be provisioned or serverless depending on concurrency and utilization, but an infrequent S3 query may be cheaper through Athena than through an idle warehouse. Time-series economics depend on ingest, retention tiers, query windows, and data volume rather than a generic per-database rate. Compare p95 and peak behavior, not just average requests. Keep failure headroom and required replicas in the model. Capacity selected for normal traffic can still be invalid if one AZ loss or a reporting surge exhausts the remaining writer, consumers, or connection budget.

A cache is an additional data system, not free performance. Use it for repeated reads with enough hit ratio, acceptable staleness, a durable backing source, and a safe invalidation or TTL policy. Price nodes or serverless units, replication, cross-AZ traffic, warm-up, misses, stampede control, and engineering effort. A cache cannot fix write saturation or a DynamoDB hot key. RDS Proxy is also not a data cache; it manages relational connections. Measure query latency, CPU, I/O, connections, item sizes, read/write units, index amplification, cache hit ratio, and eviction before adding capacity. Reversal conditions keep the architecture honest: Redshift loses to Athena for rare simple scans over well-laid-out S3; Timestream loses when ordinary relational transactions are mandatory; a specialized graph or search service loses when application rewrite outweighs its query advantage; provisioned capacity loses when traffic remains highly uncertain. The least-cost design may use several stores, but each must own a distinct, measurable access pattern and a documented source-of-truth relationship.