Redis vs Upstash vs DragonflyDB for SaaS Caching in 2026

A cache is the only piece of infrastructure I have ever added to a product and then quietly ripped back out three weeks later. It was doing nothing except adding a network hop and a second thing that could go down at 2am, because the queries underneath were already fast and the read volume was a fraction of what I had drawn on the architecture diagram.

So when the question comes up about SaaS caching, Redis, Upstash, and which one to reach for, my first answer is usually that you need a better index. Not a cache. Once you genuinely cross the line where a cache earns its keep, though, the decision stops being about latency benchmarks and turns almost entirely into a question about how your provider counts. Per command, per gigabyte, or per hour of a box you have to babysit. Those three billing models produce wildly different invoices for the identical workload, and for most B2B SaaS products the invoice is the deciding factor long before p99 latency is.

What Does SaaS Caching Actually Cost on Redis vs Upstash?

Upstash bills per command at $0.20 per 100,000, while fixed-tier Redis plans bill per gigabyte of memory regardless of traffic volume.

That single difference reorganises the whole comparison. Here is the field as it actually prices out, using each provider's published numbers:

Those numbers come from Upstash's published pricing page and their own 2026 provider-by-provider cost comparison, which is worth reading precisely because a vendor comparing itself to nine competitors has to show its arithmetic. The free tier is 256 MB, 500,000 commands a month, and 10 GB of bandwidth, which is more than enough to run a session store for a product with a few hundred users.

Note the read-region line. Upstash's comparison states that a read replica in another region costs about half the plan price, so serving reads from three regions roughly triples your bill. That is the tax on treating a cache as an edge computing primitive rather than a regional one.

The Crossover Sits Around Four Commands Per Second

Do the division. At $0.20 per 100,000 commands, one command costs $0.000002. The $20 fixed 1 GB plan buys you 10 million commands before pay-as-you-go catches up, which works out to roughly 3.9 commands per second sustained across a month. Below that, metered wins. Above it, you are paying a premium for elasticity you stopped needing.

Where Does DragonflyDB Actually Fit?

DragonflyDB is a vertical-scaling answer to a horizontal problem, worth reaching for when one big cache node beats operating a Redis cluster.

The headline claim on the project's GitHub repository is 25X more throughput than Redis, crossing 3.8M QPS on a c6gn.16xlarge, with about 30% better memory efficiency at idle. Redis is single-threaded for command execution by design; Dragonfly is not. On a 64-core machine that difference is enormous, and it is the entire pitch.

The caveats matter more than the benchmark. The same repository documents support for roughly 185 Redis commands, which it describes as approximately the Redis 5.0 API, and cluster mode as "currently supports only emulated". If your application leans on RediSearch or a genuine cluster topology, this is not a drop-in replacement no matter what the wire protocol says. Run your test suite against it in staging before you believe anyone, including me.

For a solo-maintained product the calculus is simpler than the benchmark suggests. Dragonfly is excellent when you have already decided to self-host and you want fewer, bigger nodes. It is the wrong answer when the thing you are actually trying to buy is not having to think about nodes at all.

Rate Limiting Is the Line Item Nobody Budgets For

The failure mode that catches people here is arithmetic rather than latency, and it compounds silently for months before anyone opens the invoice and traces it back.

You install a rate limiter. It feels free, because a rate limiter is "just a counter". Then you pick the sliding-window algorithm because fixed windows let a burst through at the boundary, and you enable multi-region because your users are spread across two continents. Upstash's own documentation is blunt about what happens next: using the sliding window algorithm with a multiregion setup "results in large number of commands in Redis and long request processing times", per their rate-limit algorithm docs.

Now every inbound HTTP request costs you several billable Redis commands before your handler does any work. A health check every ten seconds from three regions is not free anymore. Neither is your uptime monitor. Neither is the crawler that found your API docs and settled in to enumerate every endpoint.

How many commands does your rate limiter fire per request? If you cannot answer that from memory, you do not know what your cache costs. That is the number to instrument first, ahead of hit ratio, ahead of p99.

What Actually Changed in the Last Year

The Redis ecosystem spent two years in a licensing fight and has come out of it with more real options than it had before. Redis 8 added AGPLv3 as a third license alongside SSPLv1 and RSALv2 in May 2025, which put the core engine back inside an OSI-approved license. Valkey, the Linux Foundation fork, kept the BSD-3 lineage and became the engine AWS recommends.

The more useful change is recent and concrete. AWS announced Valkey 9.0 for ElastiCache on May 5, 2026, delivering "up to 40% higher throughput for pipelined workloads" at no additional cost. Two smaller features in that release matter more than the throughput number: per-field TTLs on hashes, and multi-database support in cluster-mode-enabled deployments. Hash field expiration is the one to notice if you are multi-tenant. It means a tenant's cached object can expire field by field instead of forcing you to model every expiring value as its own key, which is how most of us have been faking it for years.

Multi-database support in cluster mode is the other quiet win. Lightweight logical namespaces per tenant, without standing up a cluster per customer.

How Do You Actually Pick?

Pick the billing model that matches your traffic shape first, because the vendors inside each model differ far less than their marketing does.

1. Measure first. Instrument the queries you think need caching. Log the actual read rate for a week. Most products discover the hot path is three endpoints and the rest is noise.
2. Under ~4 commands per second sustained, go metered. Upstash pay-as-you-go, single region, no read replicas. It will cost single-digit dollars and it scales to zero when your product is asleep. This is the same reasoning that drives the rest of the SaaS MVP stack decisions: buy elasticity while your traffic is unpredictable, buy capacity once it is not.
3. Sustained and predictable, go fixed. A fixed Upstash tier, ElastiCache on Valkey, or Redis Cloud Essentials. At this point you are comparing memory per dollar and how much HA costs, not architecture.
4. Already self-hosting and cluster-shy, evaluate Dragonfly. One big node, your test suite green against it in staging, and a documented fallback to Redis if a command you depend on turns out to be in the missing 15%.
5. Skip the cache entirely if step 1 says so. A composite index and a smaller SELECT beat a cache you have to keep coherent.

That third option, buying HA, deserves more scrutiny than it usually gets. Upstash's Prod Pack is $200 a month per database for an uptime SLA and multi-zone HA. Redis Cloud's Pro tier with HA at 10 GB is $454 a month. If your cache is genuinely load-bearing, those are honest prices for a thing that must not fall over. If your cache is a nice-to-have that can miss and fall through to the database, paying HA prices for it is a category error.

A Note From a Product That Skipped All Three

On BookBed, the property management system I built solo, there is no Redis layer at all. It runs Flutter against Firebase and Stripe, and Firestore's own read caching plus a sensible query shape covered every hot path across six months of development and 40-plus screens. The one place a cache would genuinely earn itself is iCal sync, where the same remote calendar feed gets pulled repeatedly and parsed into the same result. That is a caching problem with a clear key and a natural TTL. Everything else was a query problem wearing a caching costume.

Actually, that undersells one thing. Going serverless end to end means your compute has no warm process to hold an in-memory map, so the cheap local cache that a long-running Node server gives you for free simply does not exist. That absence is what pushes serverless products toward Upstash specifically, and it is a better reason to adopt it than any benchmark.

Before You Provision Anything

Open your slowest endpoint's trace and find out how many database round trips it makes and how many of them return identical bytes on consecutive calls. If that number is small, you have a query to fix. If it is large and the payloads repeat, you have a cache key, and now you know which of the three billing models to price it under.

What does your rate limiter cost you per request today?