The best Upstash alternatives in 2026

Upstash solved a specific problem very well: serverless functions cannot maintain a connection pool, and Redis is a connection-oriented database. Its answer was a Redis you talk to over HTTP, billed per request, that does not care whether the caller lives for ten milliseconds. That is a genuinely good piece of engineering aimed at a genuinely real constraint.

Which is why the most useful question when looking for an alternative is not 'what else does Redis' — it is whether you still have the constraint Upstash was built for. I'm Ajay, I build PandaStack, so this is a vendor's roundup; PandaStack's position here is unusual and I will be explicit about it rather than pretend we sell a managed Redis.

Ask this before you compare anything

Can the thing calling Redis hold a TCP connection for more than one request?

• No — you are on edge functions, Lambda, Workers, or anything else that scales a fresh execution context per request. Then HTTP-addressable Redis, or a connection proxy, is not a preference. It is a requirement, and Upstash is very good at it.
• Yes — you run a long-lived server process. Then the constraint is gone, the standard Redis client with a normal pool works, and per-request billing is a cost with no corresponding benefit. Most people in this second category arrived at Upstash by inheritance rather than decision.

The second thing to check is what you actually use Redis for. A cache, a rate limiter, a session store and a job queue have very different durability requirements, and about half of the 'we need Redis' conversations turn out to be a cache that could be a map in process memory or a Postgres table with an index.

1. Redis Cloud

The first-party managed service from the people who make Redis. If what you want is real Redis with the full command set, modules, clustering and proper persistence, this is the reference implementation of the category and the thing others are compared against.

It is connection-oriented, so it does not solve the serverless problem Upstash was built for without a proxy in front. Pricing is instance-shaped rather than per-request, which is better at volume and worse for a workload that is idle most of the day.

2. Valkey on a managed cloud service

Valkey is the Linux Foundation fork that appeared after Redis changed its licence, and it is now the default 'Redis' in several managed catalogues — AWS ElastiCache, DigitalOcean and others offer it directly. Wire-compatible, so your existing client works unchanged.

Worth considering specifically if licensing is a procurement question for you, or if you want the option to run the same engine yourself later without a rewrite.

3. Cloudflare Workers KV and Durable Objects

If you are on Workers and using Upstash for cache or config lookups, the platform-native primitives are worth pricing first. KV is eventually consistent and very cheap to read; Durable Objects give you a single-threaded, strongly consistent coordination point, which is often what a Redis-based lock or counter was really doing.

Neither is Redis and neither pretends to be. There is no command set to port to — this is a rewrite of the access pattern, not a migration.

4. Postgres, honestly

It belongs on this list and it is under-recommended. If your Redis workload is sessions, feature flags, rate-limit counters or a low-volume job queue, a Postgres table you already operate is very often enough — and Postgres has grown into these jobs deliberately. SKIP LOCKED makes a competent queue, an unlogged table makes a fast cache, and LISTEN/NOTIFY covers a lot of pub/sub.

It is slower than Redis, and at high throughput that difference becomes real. The point is that a lot of teams pay for a second datastore, a second failure mode and a second on-call surface for a workload comfortably inside the first one's capacity.

5. DragonflyDB Cloud

A Redis-compatible engine rewritten for multi-core hardware, which means one large instance can do what a Redis cluster would otherwise need. Attractive when you have outgrown a single Redis node but do not want to operate sharding.

Newer and smaller than the incumbents. Compatibility is high but not total, so the honest evaluation is to run your actual command mix against it rather than trusting a compatibility percentage.

6. Momento

The closest philosophical match to Upstash on this list: a serverless cache with an HTTP and gRPC API, no instances to size, and a pricing model based on what you do rather than what you provision. If you liked Upstash's model and want a different vendor with the same shape, start here.

Also not Redis. It is a cache API with its own semantics, so you are porting call sites, not swapping a connection string.

7. Co-locating Redis with your app

This is where PandaStack sits, and it is a different answer rather than a competing product, so let me be precise: PandaStack does not sell a managed Redis. What it sells is an app that is a Firecracker microVM, and you can run Redis inside that VM alongside your process.

{
  "install_command": "apt-get update && apt-get install -y redis-server && npm ci",
  "start_command": "redis-server --daemonize yes --save '' && node server.js"
}

Your app then connects to 127.0.0.1:6379 — no network hop, no per-request billing, and no second vendor. That is genuinely excellent for a cache, a rate limiter, a session store, or anything else where losing the data on restart is an inconvenience rather than an incident.

The billing philosophy is the actual argument against per-request pricing. PandaStack has one rate card — $0.054 per active vCPU-hour and $0.0162 per working-set GiB-hour — and deliberately never bills per request, because per-request pricing makes your infrastructure cost a function of your traffic in a way that is very hard to forecast and punishes exactly the chatty cache access patterns Redis is good at.

If you do migrate

1. Write down what each key prefix is for and whether losing it is an incident. This usually shrinks the problem more than any vendor choice.
2. Check whether you use the REST API or a Redis client. Upstash's HTTP client is not a drop-in for a standard Redis client, so the migration cost differs a lot between the two.
3. Move the cache first. It is the lowest-risk workload and the one where a cold start after cutover costs you nothing but a few slow requests.
4. Keep the rate limiter for last if it is enforcing anything that matters, and dual-write during the transition.

The best outcome of an Upstash evaluation is often discovering you no longer have the problem it solves. If you moved from edge functions to a long-running server at some point — and a lot of teams quietly did — the constraint that justified the whole architecture went away and nobody revisited it.