Upstash Redis Serverless vs Memcached

The serverless problem Upstash solves

Traditional Redis is connection-oriented: a client opens a TCP connection, holds it open, and pipelines commands across it. This works beautifully for long-running application servers that handle many requests over the lifetime of one connection. It works poorly for serverless functions, which by design are ephemeral: a Lambda or Cloudflare Worker may handle one request then terminate, paying connection setup overhead on every request.

For the AWS Lambda + ElastiCache pairing, the workaround was Lambda VPC integration plus connection pooling at the Lambda runtime level, with cold-start penalties for the first invocation in each container. For Cloudflare Workers, even this was impossible: Workers cannot hold arbitrary TCP connections (the runtime is sandboxed). The result was that the most actively-deployed serverless platforms of the early 2020s had no good Redis option.

Upstash's answer was to expose Redis over HTTP/REST. Each command is a separate HTTP request, with authentication via a token header. The client SDK (@upstash/redis) translates Redis commands into HTTP calls and returns the response in the expected shape. Because each request is independent, it works fine inside Cloudflare Workers, Vercel Edge, AWS Lambda@Edge, and any other sandbox that allows outbound fetch. The penalty is HTTP overhead per command, mitigated by batching (a single HTTP call can carry a pipeline of commands).

The pricing model and when it makes sense

Upstash bills per command and per GB of storage. The free tier in 2026 includes 10,000 commands per day and 256MB of storage. The Pay-as-you-go tier charges roughly $0.20 per 100,000 commands and $0.25 per GB-month of storage, with no minimum and no idle charges. For a serverless app handling a few hundred thousand commands a day this can cost under a dollar a month.

The Pro plans introduce monthly fixed pricing with included throughput, designed for higher-volume workloads where the per-command pricing would become uneconomical. The crossover point is around 50-100 million commands per month, depending on storage size and global replication needs. Below that, pay-as-you-go is usually cheaper than any traditional managed Redis. Above that, ElastiCache or Memorystore on a reserved-instance commit tends to win on pure command throughput per dollar.

The implicit cost saving with Upstash is the absence of idle cost. A traditional ElastiCache cluster runs 24/7 whether traffic is one request per hour or a thousand per second. Upstash charges for actual commands; a near-zero traffic period costs near zero. For staging environments, internal tools, and applications with bursty traffic patterns, this asymmetry is what makes Upstash attractive beyond just the serverless integration story.

Global replication and edge proximity

For applications running at the edge (Cloudflare Workers in particular), the latency from the edge node to a centrally-hosted Redis can become the dominant factor in request time. A Worker in Singapore reading from a US-East Redis pays ~200ms round-trip per read, defeating much of the edge speed advantage. Upstash addresses this with global replication: a single logical Upstash Redis database can have read replicas in 5+ regions worldwide, and the SDK routes reads to the geographically closest replica automatically.

The replication is eventually consistent across regions: writes go to a primary (usually the region where the database was provisioned), and replicate asynchronously to the other regions within a few hundred milliseconds. For caching workloads this is usually fine; for write-heavy or strict-consistency workloads you have to accept that a read immediately after a write to a different region may return stale data. The same trade-off applies to any cross-region replication setup including ElastiCache global datastores and Redis Enterprise active-active.

For genuine multi-region active-active workloads with conflict resolution, Redis Enterprise on Redis Cloud (covered in a separate guide) and CRDT-based stores like Riak are the better fit. Upstash global replication is best understood as a read-acceleration feature for predominantly read-heavy edge workloads, not a multi-master replication system.

Why no Upstash Memcached

The absence of Memcached from Upstash's product line is structural, not accidental. Memcached's text protocol assumes a long-lived TCP connection; the binary protocol assumes the same. There is no widely-adopted HTTP/REST gateway for Memcached because no one with serious interest in the question has built one and the use case is small. The Memcached community has generally taken the position that the connection-oriented model is correct and serverless workloads should use Redis or accept the limitations.

From Upstash's product strategy perspective, the addressable market for serverless Memcached is small to nonexistent. Customers reaching for serverless cache reach for Redis 95% of the time (because the additional Redis features are usually wanted), and the remaining 5% either accept Redis or run something self-hosted on their own infrastructure. Building a serverless Memcached service would not create much new demand.

The practical implication for teams: if you are committed to Memcached for legacy or specific-throughput reasons, you cannot get a serverless version of it. You can run Memcached on AWS Lambda Extensions, on Fargate, on GKE Autopilot, or on Cloud Run, but the operational model is "managed compute hosting your own Memcached," not "managed Memcached as a service." For new serverless designs, the recommendation is to default to Upstash Redis (or another serverless Redis like Redis Cloud's serverless tier) and treat Memcached compatibility as a non-goal.

FAQ

Related decisions