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 an AWS c6i.2xlarge in single-key workloads. At 1k QPS we are running at well under 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
The always-on managed-instance model looks inefficient only when the box sits mostly idle: a cache.t4g.micro costs $11/month even if you use it just from 9am to 5pm on weekdays. But serverless does not automatically mean cheaper. Upstash Redis charges per request at $0.20 per 100k commands, so traffic that genuinely sustains 1k QPS is about 2.6 billion commands a month, roughly $5,184, several hundred times the price of the smallest always-on node. Per-request pricing only wins when the true average rate is far below the peak.
Per-request pricing is attractive only when the average request rate is genuinely low, even if brief peaks are higher: a hobby project, an internal tool hit a few times an hour, an endpoint that spikes for minutes then goes quiet. Once a workload holds anywhere near 1k QPS for sustained periods, metered requests overtake a flat plan or a small always-on node quickly. Model your real monthly command count against the $0.20-per-100k rate before assuming serverless is the cheap option.
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
Memcached's raw GET/SET throughput edge at high concurrency (around 25% in one independent benchmark: Dev Genius, March 2026, AWS c6i.2xlarge) 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?
Only if your true average request rate is low or very bursty, not at a sustained 1k QPS. Upstash Redis pay-as-you-go bills $0.20 per 100k commands (checked September 2026); a sustained 1,000 QPS is about 2.6 billion commands a month, roughly $5,184, far more than the ~$11/month smallest ElastiCache node. Per-request pricing only wins when the average rate sits well below the peak. If you want a managed, no-node option at this volume, Upstash's Fixed plan is a flat $10/month (250MB, unlimited commands).
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.