Redis vs Memcached at 1k QPS
One thousand queries per second is the low-traffic baseline for most production caches. At this volume both stores are essentially idle and any engine differences are invisible. The interesting cost and operational questions live elsewhere.
What 1k QPS actually feels like
A thousand queries per second is roughly the upper end of "small production workload": a SaaS product with a few hundred active users, an e-commerce site with steady but not viral traffic, an internal tool used by a few teams. At this load both Redis and Memcached are running at single-digit-percent CPU on the smallest production node sizes. The server is mostly idle, occasionally processing a request, then idle again.
The 2026 DevGenius benchmark (the same one cited elsewhere on this site for the high-concurrency comparison) reports both engines comfortably above 100k QPS on a cache.r7g.large in single-key workloads. At 1k QPS we are at roughly 1% of that capacity. The server-side processing time for a typical GET or SET is well under 100 microseconds. The end-to-end latency seen by the application is dominated by network round-trip time, which is 0.5-2ms within an AWS region depending on AZ topology.
At this throughput, the engine choice has no practical impact on latency or cost. The smallest ElastiCache node (cache.t4g.micro at $11/month on-demand) costs the same for Redis or Memcached and handles 1k QPS without breaking a sweat. The reserved-instance discounts are barely worth pursuing because the absolute numbers are tiny. The operational concerns (monitoring, alerting, snapshot retention) are the same.
The serverless alternative
For workloads in the 1k QPS range, the always-on managed-instance model starts to look inefficient. A cache.t4g.micro costs $11/month even if you only use it from 9am to 5pm on weekdays. A serverless option like Upstash Redis charges per request: at $0.20 per 100k commands, 1k QPS sustained for a month is roughly $52, but bursty traffic that averages 1k QPS but peaks at 5k for a few hours can come out around the same as always-on.
The serverless economics are most attractive when traffic is heavily bursty or seasonal. A B2B SaaS that is busy during business hours and idle overnight saves significantly on a per-request model. A consumer app with predictable evening peaks pays roughly the same either way. A bot-traffic-heavy site where you cannot predict the load benefits from the pay-per-use cap.
Memcached has no serverless option, as discussed in the Upstash guide. For low-traffic workloads where you would actually consider serverless, this absence pushes the decision toward Redis or Valkey by default. The Memcached camp essentially has one option (smallest always-on managed instance) and that option is fine but rarely cheapest.
Replication: how much HA do you need?
At 1k QPS the question of replication has nothing to do with throughput (the primary is bored) and everything to do with availability. A single Redis or Memcached node that goes down due to AZ failure, OOM, hardware fault, or operator error takes the cache with it. For a pure cache where misses fall back to the underlying database, this is a temporary performance degradation. For sessions, rate limits, or other stateful workloads, it is an outage.
The cost calculation for HA at 1k QPS: adding a Redis replica doubles the storage cost (you pay for primary plus replica on the same node size). For our cache.t4g.micro example, that takes $11/month to $22/month. The availability gain is meaningful: failover from primary to replica takes seconds and is usually automatic. For workloads where cache loss is genuinely costly, this is good value.
Memcached cannot offer this trade-off because it does not support replication. The Memcached HA story is to run more nodes (each holding a fraction of the keyspace) and accept that a single-node failure loses only the keys hashed to that node, with the application repopulating from the data source. For sessions this is unacceptable; for pure cache it can be tolerable depending on how expensive cache misses are.
What the benchmark numbers actually mean here
The ~25% Memcached throughput edge cited elsewhere on this site (DevGenius March 2026, AWS c6i.2xlarge, simple GET/SET at high concurrency) is a peak-load measurement. At 1k QPS that edge is invisible because neither store is anywhere near peak. If Memcached can do 1.0 million GETs per second and Redis can do 800k, both are doing 1,000 GETs per second comfortably. The percentage difference at the limit does not translate to a percentage difference at low utilisation.
Latency at 1k QPS is essentially noise. Both stores serve requests in well under 100 microseconds on the server side. The dominant latency component is network round-trip (typically 0.5-2ms within an AWS region) plus client-side serialization and deserialization. The choice of engine adds variance in the noise.
The implication for engineering decisions: at 1k QPS, pick the engine that fits your application's feature requirements and your operational preferences. Performance is not a real input to the decision. The interesting performance comparison happens at 10k+ QPS where CPU utilisation starts to matter, and at 100k+ QPS where the engine differences become load-bearing. See the 100k QPS guide for where the throughput edge actually matters.
FAQ
What hardware should I pick for 1k QPS?
The smallest you can get. AWS ElastiCache cache.t4g.micro (2 vCPU, 0.5GB RAM) handles 1k QPS comfortably for either Redis or Memcached on a typical key-value workload. Cost is around $11/month on-demand. The smaller you can go, the better; for sub-1k-QPS you might want a serverless option.
Is latency the same?
Indistinguishable at this load. Both stores serve requests in sub-millisecond on the server side. The end-to-end latency seen by your application is dominated by network round-trip (typically 0.5-2ms within a region) plus client-side serialization. The choice of engine adds negligible variance.
Should I use serverless instead?
Probably yes for 1k QPS. Upstash Redis pay-as-you-go would cost roughly $0.10-0.20 per million commands, putting 1k QPS at around $25-50 per month. Compare to ~$11/month for the smallest ElastiCache node plus data transfer. Serverless wins for low-traffic workloads where the per-request cost ends up below the always-on instance cost.
Do I need replication at 1k QPS?
Depends on the workload. Caching that can survive cache misses on a failover: no, single node is fine. Sessions or critical state that cannot lose data: yes, a primary + replica setup is worth the 2x cost. Memcached has no replication option, so you accept the single-node risk.
What about latency p99?
At 1k QPS, both stores comfortably stay sub-2ms at p99 on healthy hardware. Spikes come from network issues, GC pauses on the client side, occasional disk I/O for AOF fsync on Redis, slab reorganisation on Memcached. None of these are load-correlated at this throughput.