Upstash vs Redis Cloud in 2026

Short version: pick Upstash when your traffic is spiky or small and your code runs on an edge runtime, because it bills per command, reaches Redis over HTTP, and its free tier gives you 500K commands a month with 256 MB. Pick Redis Cloud when your traffic is steady or you need the Redis 8 feature set, because it bills by memory size rather than by request and it is the only place the search, JSON, and time series capabilities are first-party. The crossover is not subtle: a small always-on app that does about 12 million commands a month is roughly $24 on Upstash pay-as-you-go and about $5 on Redis Cloud Essentials, while an app doing 400K commands a month in bursts is free on Upstash and already over the free ceiling on Redis Cloud. All numbers below were checked on the vendors' own pages in September 2026.

I run Layerbase, which hosts Redis and Valkey on flat plans, so I have a stake in this. The comparison below stands without it, and there is one clearly marked section at the end where I say where we fit and where we do not.

Contents

• The two billing models
• Free tiers, side by side
• What a small always-on app costs
• What a bursty serverless app costs
• HTTP access and edge runtimes
• Connection limits are the quiet ceiling
• Persistence and durability
• Multi-region and global replication
• Redis version and feature coverage
• Licensing, briefly
• Where ElastiCache lands in this
• Where Layerbase fits
• FAQ

The two billing models

This is the whole comparison, so it goes first.

Upstash has three shapes. The free database is capped at a command count. Pay-as-you-go charges $0.2 per 100K commands, $0.25 per GB of storage after the first gigabyte, and bandwidth free to 200 GB a month then $0.03/GB. Fixed plans replace the command meter with a monthly number tied to a size: $10 for 250 MB, $20 for 1 GB, $100 for 5 GB, $200 for 10 GB, up to $1500 for 500 GB. The Prod Pack, which adds the uptime SLA and multi-zone HA, is +$200/month per database. Verified as of September 2026 from upstash.com/pricing/redis.

The part people miss: Upstash is only a meter on pay-as-you-go. On a fixed plan the commands stop being billable and the throughput cap takes over instead, at 10,000 commands per second on every plan up to 10 GB and 16,000 on the largest two, per the Upstash pricing docs.

Redis Cloud never meters requests. It sells memory and throughput as a plan. Free is $0 for up to 30 MB. Essentials starts at $0.007/hour, about $5/month, covering 250 MB to 100 GB on a shared deployment with one database. Pro starts at $0.014/hour with a $200/month minimum and is the first tier with a dedicated deployment, multiple databases in the subscription, and Active-Active. Verified as of September 2026 from redis.io/pricing.

So the question "which is cheaper" has no general answer. It has an arithmetic answer per workload, and the variable is how many Redis calls sit behind one user action.

Sources for the table rows: the two pricing pages above, the Redis Cloud Essentials plan limits, the Upstash compatibility page, and the Redis Cloud changelog.

Free tiers, side by side

Both are real free tiers rather than trials, and they run out of completely different things. Checked in September 2026.

The Upstash free tier ends on volume. 500K commands a month is about 11 a minute sustained, which is a lot for a side project and nothing for a cache that is doing its job. The Redis Cloud free tier ends on shape: 30 MB is fine for sessions, and the numbers that actually bite are the 30 concurrent connections and the 100 operations per second, both published in the Essentials plan table. A serverless deployment that opens a connection per invocation hits 30 connections long before it fills 30 MB.

That is the cleanest way to hold the two apart. Upstash free fails on how much you use it. Redis Cloud free fails on how you are shaped. I ran this exercise across more vendors in Redis free tiers compared.

What a small always-on app costs

Take an ordinary web app on a single region: 50,000 requests a day, eight Redis commands per request (a session read, a rate-limit INCR, two cache reads, a cache write, a couple of EXPIRE calls), and about 120 MB of live keys. That is 12 million commands a month, averaging under 5 operations a second.

Upstash pay-as-you-go: 12 million commands at $0.2 per 100K is $24. Storage is inside the first free gigabyte, so $24 a month.

Upstash fixed 250MB: $10 a month, no command charge, and 120 MB fits. The 50 GB bandwidth allowance is the thing to check rather than the request count.

Redis Cloud Essentials 250 MB: the published floor is $0.007 an hour, which is about $5.11 over a 730-hour month. Under 5 ops a second is comfortably inside the 1000 ops/sec cap, and 256 concurrent connections is more than a handful of app servers need.

For this shape Redis Cloud is the cheaper product, and it is not close: the metered path costs roughly five times the plan that just holds the data. This is the case where per-command billing works against you, because steady traffic is exactly the thing a fixed price is good at absorbing.

What a bursty serverless app costs

Now change one variable. Same app, but it is a set of serverless functions, traffic is concentrated into short bursts, and the monthly total is 400,000 commands with about 60 MB of keys.

Upstash: 400K commands is inside the 500K free allowance, so $0. If it grows to 2 million commands, pay-as-you-go is $4 a month. There is no connection to hold because the client speaks HTTP.

Redis Cloud: 60 MB is already past the 30 MB free ceiling, so this starts on Essentials at about $5 a month. The sharper issue is the burst: 100 ops/sec on free and 1000 ops/sec at 250 MB are averages you can exceed in a spike even when your monthly total is tiny, and a fan-out of concurrent function invocations has to fit inside the connection cap or go through a proxy.

For this shape Upstash is the better fit, and the free tier alone may cover you for a year. The pattern generalizes: pay-as-you-go rewards workloads whose peak is far above their mean, because you pay for the area under the curve rather than for the height of it.

If you want the same arithmetic run against Neon, Aurora, D1, and Turso as well, that is what each serverless meter actually counts.

HTTP access and edge runtimes

Upstash's REST API is the reason it exists. A Cloudflare Worker, a Vercel Edge Function, or anything else that cannot open and hold a TCP socket can call Redis with fetch, and the @upstash/redis client wraps that. Lua scripting is available over the same REST interface. If your code runs on an edge runtime, this is a capability question, not a pricing preference.

Redis Cloud does not offer an HTTP interface to the keyspace. You connect with RESP over TCP, the same way redis-cli, ioredis, redis-py, and BullMQ have always connected. On a normal Node or Go service that is the better arrangement, because you keep a pooled connection open instead of paying TLS setup on every call. On an edge runtime it is a wall, and the usual workaround is putting your own HTTP service in front, which is a thing to operate.

This single row decides a surprising number of these comparisons on its own.

Connection limits are the quiet ceiling

Redis Cloud publishes concurrent connections per plan, and the ladder is steep at the bottom: 30 on free, 256 at 250 MB, 1024 at 1 GB, 2500 at 2.5 GB, 5000 at 5 GB, 10000 at 12 GB, from the Essentials plan table. That is fine for a fleet of long-lived app servers and awkward for anything that scales connections with traffic.

Upstash does not publish a per-plan connection number in the same way, because the HTTP path does not hold connections at all. It publishes a throughput cap instead, 10,000 commands per second up to the 10 GB plan. If you connect over the RESP endpoint rather than REST, concurrent connections do become a real limit and the error to look for is ERR max concurrent connections exceeded.

Practical translation: on Redis Cloud, count your connections. On Upstash, count your commands per second.

Persistence and durability

Upstash writes to block storage in addition to memory, and describes the product as persisting data so that it can be used as a primary database rather than only a cache. That is a stronger default than a plain Redis instance with snapshots.

Redis Cloud's durability is a per-plan setting. The free 30 MB plan has no backups and no replication. Paid Essentials plans add high availability and both daily and instant backups, which the plan documentation calls out as the reason paid starts at 250 MB. Pro adds the dedicated deployment and the 99.999% SLA.

The thing to know is that "Redis is in memory so treat it as disposable" is now a statement about your own configuration, not about the products. Both of these will keep your keys across a restart if you are on a plan that says so.

Multi-region and global replication

Upstash global databases put one primary region and any number of read regions behind a single URL, with reads served from the closest replica. The cost model is worth reading twice, from the global database docs: "Global Database charges $0.2 per 100K commands. The write commands are replicated to all read regions in addition to primary region so the replications are counted as commands. For example, if you have 1 primary 1 read region, 100K writes will cost $0.4." On fixed plans a read region is instead a flat add, +$5/month on the 250MB plan and +$10 on the 1GB plan. Writes are asynchronous to the read regions, so this is eventual consistency for readers.

Redis Cloud's answer is Active-Active, CRDT-based geo-replication where every region accepts writes and conflicts merge deterministically. It is a Pro feature, so the floor is $200 a month, and the documentation notes that multi-region deployments involve an annual plan and a sales conversation.

These are different products, not two prices for the same thing. Read-local caching with one writer is Upstash's model and it is cheap to start. Multi-master writes across continents is Redis Cloud's model and nothing on the Upstash price list substitutes for it.

Redis version and feature coverage

Redis Cloud runs Redis itself. The changelog shows Redis 8.6 landing on Essentials in May 2026 and on Pro in July 2026, with 7.2, 7.4, 8.0, 8.2, and 8.4 also documented. Since Redis 8, the capabilities that used to be separate modules, the query engine and secondary indexing, JSON documents, time series, and the probabilistic structures, are shipped as part of Redis Open Source rather than as add-ons, so FT.SEARCH, JSON.GET, and TS.ADD are first-party commands there.

Upstash is a reimplementation that speaks the protocol. Its compatibility page states support for "Redis client protocol up to version 8.4", and it has its own answers for the higher-level surfaces: JSON.* commands natively, a Tantivy-based Upstash Redis Search, and VECTOR.* commands. It also says plainly that some items are unsupported and on the roadmap.

What this means when you are choosing: if you are using plain key-value Redis, both are complete and the choice is entirely about price shape and connection model. If you depend on the module-level surface, check your exact command list against both. Upstash covering JSON.* does not make it a drop-in for a codebase built on RediSearch aggregations, and the compatibility page does not enumerate every gap.

Licensing, briefly

Redis changed its license in March 2024 to the dual RSALv2 and SSPLv1, neither OSI-approved, and then added AGPLv3 as a third option with Redis 8 in May 2025. That is what put the modules into the main distribution and why Redis Cloud can sell them as core rather than as extras. Valkey is the Linux Foundation fork of the pre-change 7.2 line and stays BSD-licensed.

Neither of the two products here is open source as a service: Upstash is a proprietary implementation, and Redis Cloud is Redis Ltd.'s hosted commercial offering. Licensing matters for what you can self-host later, not for what you are buying today. Redis vs Valkey covers the fork and where it stands now.

Where ElastiCache lands in this

People searching for this comparison often have ElastiCache in the mix, so briefly. AWS ElastiCache Serverless for Valkey bills $0.084 per GB-hour of data stored plus $0.0023 per million ECPUs, where reads and writes consume one ECPU per kilobyte transferred, with a minimum of 100 MB of billed storage per cache. AWS states ElastiCache for Valkey "starts at $6/month", which is what that storage floor works out to before any request charges, and that the Valkey engine is 20% cheaper than the others on node-based pricing. Verified as of September 2026 from the ElastiCache pricing page.

Two ECPUs of nuance. First, ECPUs scale with payload size, so a cache holding 4 KB values costs four times as much per operation as one holding 1 KB values, which makes an Upstash-style per-command comparison misleading unless you know your average value size. Second, ElastiCache lives inside a VPC. There is no public endpoint and no HTTP interface, so it is not a candidate for an edge runtime at all, and it is a good candidate when your compute is already in the same AWS account and region. Compared with Upstash it is cheaper at steady high volume and much more work to operate; compared with Redis Cloud it is a similar deal without the query engine and without a free tier.

Where Layerbase fits

This is the section I flagged at the top. Layerbase hosts Redis and Valkey among the 18 engines on Layerbase Cloud, and the case against both vendors above is a specific one rather than a general better.

Flat plans with no request meter. Free is $0 with no card: 2 databases, 5 GB, 8 engines including Redis and Valkey, up to 20 concurrent connections. Solo is $5/month for 2 databases with one pinned always-on, 10 GB, and 100 connections. Pro is $15/month for up to 10 databases, 25 GB, 500 connections, all 18 Cloud engines, and 30-day backups. Commands are never counted on any of them. The whole list is on the pricing page.

Be clear about the free tier, because it is the relevant caveat here. A free Layerbase database sleeps after 15 idle minutes and wakes on the next connection, about one to five seconds. That is fine for development, CI, and a side project. It is the wrong default for a production cache, where a cold first connection during a traffic spike is exactly what you do not want, so an always-on cache belongs on a paid plan where the database is pinned to the always-on pool. Sleep vs pause vs archive explains the states, and the lifecycle docs have the full state machine. Upstash's free tier does not sleep, and that is a genuine advantage of theirs at hobby scale.

The Upstash client keeps working. Every Redis and Valkey database exposes an Upstash-compatible REST endpoint next to the rediss:// port, so @upstash/redis and @vercel/kv point at a new URL and token and nothing else in the code changes. That covers the edge-runtime case Redis Cloud has no answer for. Details are in the serverless and edge docs. Every Valkey database also carries an HTTP queue that the @upstash/qstash client speaks, included with the database rather than sold as a second product.

Branching, which neither vendor offers. A Redis or Valkey database on Layerbase can be branched, so a preview environment or a test run gets its own copy of the keyspace instead of sharing a namespace. That is the feature I would actually move for if pricing were a wash.

Where we are the wrong choice. We have no modules: FT.*, JSON.*, and TS.* do not exist on our Redis 7.2 or Valkey 9.0, so a codebase on the Redis 8 query engine should stay on Redis Cloud. We have no Active-Active and no global read regions, so a cache that has to be local to three continents is Upstash or Redis Cloud Pro. We do not sell a 99.999% SLA, RBAC, or SAML on shared plans. And if your workload genuinely lives under 500K commands a month, Upstash free costs nothing and never sleeps, which is hard to beat with a $5 plan.

If none of those apply and what you run is a cache, a session store, a rate limiter, or a queue, create a Valkey database and point your existing client at it. The longer versions of each side are Upstash alternatives and Redis Cloud alternatives, the step-by-step move is migrating from Upstash to Layerbase, and if your store came from the Vercel Marketplace, Vercel KV alternatives covers that wrinkle.

FAQ

Is Upstash cheaper than Redis Cloud?

It depends on request volume, and the crossover is lower than most people expect. As of September 2026, Upstash pay-as-you-go is $0.2 per 100K commands while Redis Cloud Essentials starts at about $5/month for 250 MB. An app doing 12 million commands a month is about $24 on the Upstash meter and about $5 on Redis Cloud. An app doing under 500K commands a month is free on Upstash and needs a paid Redis Cloud plan the moment it exceeds 30 MB or 30 connections. Upstash's own fixed plans, $10 for 250 MB, sit between the two and remove the command meter.

Which has the better free tier, Upstash or Redis Cloud?

Upstash's, for most people: 256 MB and 500K commands a month against Redis Cloud's 30 MB, 30 concurrent connections, and 100 ops/sec. Redis Cloud's free database is sized for learning and prototypes, which is how its own documentation describes it. The exception is a workload with a small keyspace and steady modest traffic from a few long-lived servers, where 30 MB is enough and the command count on Upstash would run out.

Can I use Redis Cloud from a Cloudflare Worker or Vercel Edge Function?

Not directly. Redis Cloud speaks RESP over TCP and publishes no HTTP interface to the keyspace, so a runtime that cannot hold a socket needs a proxy service you run yourself. Upstash's REST API exists for exactly this case, and it is the main reason to choose it independently of price.

Does Upstash support Redis modules like RediSearch and RedisJSON?

Upstash has its own implementations rather than the Redis Ltd. modules. Its compatibility page documents support for the Redis client protocol up to version 8.4, native JSON.* commands, a Tantivy-based Upstash Redis Search, and VECTOR.* commands, while noting that some items remain unsupported. Redis Cloud runs the real thing, and since Redis 8 the query engine, JSON, time series, and probabilistic structures are part of Redis Open Source rather than separate modules. Check your exact command list against both before assuming a port is free.

How does Upstash multi-region pricing work?

On pay-as-you-go, every write is billed once per region it lands in: the docs give the example that with one primary and one read region, 100K writes cost $0.40 rather than $0.20. On fixed plans a read region is a flat monthly add, +$5 on the 250MB plan and +$10 on the 1GB plan. Reads are served locally and replication is asynchronous, so read regions give you latency, not multi-master writes.

How does ElastiCache compare on price?

ElastiCache Serverless for Valkey is $0.084 per GB-hour of stored data plus $0.0023 per million ECPUs, with one ECPU per kilobyte transferred and a 100 MB minimum billed per cache, which is the $6/month floor AWS quotes. That is competitive at steady volume and unusable from an edge runtime, since there is no public endpoint. It makes sense when your compute is already in the same VPC and you are prepared to run it.

What if I want Redis without any usage meter at all?

That is the flat-plan category, and it is what we sell: Layerbase runs managed Redis 7.2 and Valkey 9.0 with no command counting, a free tier whose databases sleep after 15 idle minutes and wake on connect, and paid plans starting at $5/month where a pinned database stays awake. You give up the Redis 8 module surface and multi-region writes to get there, which is the trade to weigh.

The wrap-up

Upstash and Redis Cloud are not competing on the same axis. Upstash sells access: HTTP, no connection management, a meter that starts at zero and follows your usage upward. Redis Cloud sells the engine: the real Redis, the query engine and JSON that ship with it now, Active-Active, and a price that follows your data size rather than your traffic.

Work out your commands per month and your concurrent connections before you look at either price list. Those two numbers pick the product for you almost every time, and everything else in this post is a tiebreaker.