Per-Request Redis Is Cheap Until It Isn't: The $0.20-per-100K Crossover Against Fixed Plans and Self-Hosted Valkey

$0.20 per 100,000 commands sounds like free. That is the entire pitch of serverless Redis: stop paying by the hour for a cache node that idles overnight, and pay by the command instead. Upstash's pay-as-you-go Redis prices every command identically — reads and writes, $2.00 per million — with the first gigabyte of storage free, bandwidth free to 200 GB a month, and an idle database billing exactly $0.

Here is the crossover math up front, because the rest of this post is just the receipt. The free tier covers 500,000 commands a month, so side projects pay nothing. Past that, pay-as-you-go beats the $10/month fixed plan until roughly 5 million commands a month — and beats a ~$5/month self-hosted Valkey slice until roughly 2.5 million. Past 5 million, the $10 fixed plan with unlimited commands wins by a margin that only widens: at 50 million commands a month, the meter reads $100 against the fixed plan's $10. At 500 million, it reads $1,000.

The uncomfortable version: per-request pricing is the cheapest Redis available and the most expensive Redis available, separated by one order of magnitude of command volume. Which side you land on depends entirely on how chatty your workload is — and most teams have never counted.

The three price shapes, side by side​

Upstash publishes three ways to pay for the same Redis-protocol database, and its 2026 comparison posts lay the numbers out plainly. The table below adds the two outside options a self-hosting team actually weighs: a Valkey you run yourself, and Cloudflare KV for the reads-heavy edge case.

Three details in that table do more work than they appear to. First, Upstash bills reads and writes identically, while Cloudflare KV splits them 10-to-1 — KV is 4x cheaper per read than Upstash pay-as-you-go, but 2.5x more expensive per write, and it is eventually consistent with no pub/sub, streams, or Lua. Reads-heavy reference data and write-heavy session state are different buying decisions.

Second, every Upstash paid plan already includes replication with automatic failover. A lone self-hosted node is a single point of failure; matching managed durability yourself means a second box, Sentinel or a cluster setup, and the on-call rotation to notice when it fails over at 3 AM. The $5-vs-$10 comparison is honest on hardware and incomplete on operations — more on that below.

Third, the fixed plan's "unlimited commands" shares the same 10,000-commands-per-second ceiling as pay-as-you-go. Throughput headroom is not what the upgrade buys; it buys freedom from the meter. If your workload bursts past 10K cmd/s sustained, neither $10 option is your plan — you are shopping fixed tiers up to the $1,500/month end of the range, or your own hardware.

The crossover math on a typical workload​

Take a conventional small production app: session storage, API rate limiting, and a background-job queue. Say 50,000 active sessions a day at 2 commands each (one read, one write), 200,000 rate-limit checks at 1 command each, and 10,000 queued jobs at 5 commands each (enqueue, claim, ack, plus two status reads). That totals 350,000 commands a day — roughly 10.5 million a month.

On pay-as-you-go, minus the 500K free tier, that is 10 million billable commands: about $20 a month. On the $10 fixed plan: $10. On a self-hosted Valkey sharing a Hetzner CX22 (around $5 a month for the whole 2-vCPU, 4 GB box): $5 of hardware you were probably already paying for. The fixed plan wins at half the meter price, and self-hosting halves it again — before counting anyone's time.

Now shrink the app to an early-stage service doing 100,000 commands a day, about 3 million a month. Pay-as-you-go bills 2.5 million after the free tier: about $5. The fixed plan still costs $10. Self-hosting still costs $5 in hardware plus your evening. Here the meter wins outright — half the fixed price, zero operational surface, and it scales to zero on the days nobody visits.

The full sensitivity picture, assuming a dataset under 250 MB so storage never binds:

Two footnotes keep this table honest. The asterisk on 500M commands: that volume averages under 200 commands per second, comfortably inside the 10K cmd/s ceiling — but if those commands arrive in sharp bursts (flash sales, cron stampedes), the ceiling binds on bursts, not averages. And the "+ ops" on self-hosting is doing real work in every row: patching, backups, failover testing, and the 3 AM page are costs even when they are not invoices. A solo dev's evening has a price; a team's on-call rotation has a bigger one.

Where per-request wins: idle-to-zero and spiky​

The meter's home turf is workloads where the average day looks nothing like the busy day — or where most days look like nothing at all. Three shapes dominate.

Staging, preview, and side projects are the obvious case. A preview database per pull request that serves a few thousand commands during review and then sits idle for weeks costs cents on pay-as-you-go and $0 when truly idle. The equivalent fixed or always-on fleet multiplies a flat fee by every environment. Teams running dozens of ephemeral environments feel this first: the meter turns environment sprawl from a budgeting problem into a rounding error.

Spiky edge and serverless workloads are the second. A Cloudflare Worker or Vercel function that needs Redis-protocol access — rate limiting at the edge, feature flags, small session reads — fires commands in bursts around traffic and goes quiet overnight. Upstash speaks both the Redis TCP protocol and HTTPS REST from the same database, so the same storefront works from Workers, Lambda, a Node server, or a browser. Paying $2 per million for bursty edge commands beats holding a connection-pooled node open 24/7 for traffic that exists 6 hours a day.

The third is the free tier as a genuine production tier for tiny apps. Five hundred thousand commands and 256 MB cover a surprising amount of real software: a queue doing 1,000 jobs a day at 5 commands per job burns 150,000 commands a month, under a third of the free allowance. The failure mode here is success — the day the app outgrows the free tier it lands on the meter, and the meter's slope is the subject of the next section.

Where the meter becomes the most expensive Redis in the building​

Every billing model has a workload shape that punishes it, and the meter's is chattiness: many small commands doing individually trivial work. Redis-protocol workloads drift toward chattiness by default, because the protocol makes each round trip cheap in latency and invisible in code. Four patterns deserve an audit before you commit to per-command billing.

Job queues and polling loops are the classic trap. A worker that polls a queue key every 100 ms burns 864,000 commands a day per worker — 26 million a month — before processing a single job. Blocking pops (BLPOP) collapse that to near zero, but plenty of queue libraries default to short polling, and each poll is a billed command whether the queue was empty or not. Multiply by a worker fleet and the meter reads like a DDoS you inflicted on your own invoice.

Pub/sub fan-out and per-message bookkeeping scale the same way. A chatty pub/sub topology where each published message triggers subscriber-side reads, presence updates, and unread counters can easily spend 10+ commands per user-visible event. At $2 per million that is $0.00002 per event — until a million events a day make it $20 a day, $600 a month, for what the fixed plan would have absorbed at $10.

Rate limiting and analytics counters look innocent per request and compound brutally. A rate limiter doing a read-plus-increment per API call doubles the command count of every endpoint it guards. The bloom-filter tutorial on Upstash's own blog makes the arithmetic explicit: 7 SETBIT commands per add means a million adds cost 7 million commands — $14 — and pipelining does not help, because 7 pipelined commands are still 7 billed commands. Pipelines save round trips, not money. Any optimization that reduces latency without reducing command count is invisible to the meter.

The honest bottom line: if your workload's natural shape exceeds ~5 million commands a month and grows with traffic, the meter is not a pricing plan, it is a success tax. Ten million commands cost double the fixed plan; fifty million cost ten times it; and unlike the fixed plan, the meter has no ceiling to hit — it just keeps reading. The teams with horror stories all share one trait: they never instrumented command volume until the invoice did it for them.

The Valkey escape hatch: flat hardware, real license, your pager​

There is a third option beyond choosing which Upstash plan to be on, and its existence traces to March 2024, when Redis Inc. moved Redis off the BSD license to dual SSPL/RSALv2 terms. Four days later the Linux Foundation launched Valkey, a BSD-3-Clause fork of Redis 7.2.4 backed by AWS, Google Cloud, Oracle, and Ericsson. By April 2025, Valkey 8.1 had reached feature parity while improving memory efficiency — and it now ships as the default Redis-compatible server in Ubuntu, Debian, and Fedora. (Redis itself returned to open source with Redis 8 under AGPLv3, so the license story has two acceptable endings; Valkey's permissive BSD terms remain the simpler one for redistributors.)

For a self-hosting team the economics are stark. A Hetzner CX22 — 2 vCPUs, 4 GB of RAM, 40 GB SSD, 20 TB of traffic — costs around €4–5 a month, and a Valkey instance serving a sub-gigabyte dataset barely notices it is sharing the box. The wire protocol and every mainstream client (ioredis, node-redis, redis-py, go-redis) work unchanged; several projects document the migration as a one-line image swap. Against the sensitivity table above, self-hosted Valkey undercuts the meter from ~2.5 million commands a month upward and undercuts the $10 fixed plan immediately — on hardware cost.

What the hardware comparison omits is the managed middle you give up. Upstash's paid plans bundle replication and automatic failover; your single Valkey node has neither until you build it. Managed Valkey exists in the gap — ElastiCache for Valkey runs up to 33% cheaper than ElastiCache for Redis on equivalent nodes — but on flat-rate Hetzner hardware the managed premium mostly buys back the pager, not the performance. So the real question is operational, not financial: does your team already run stateful services with backups, monitoring, and a failover runbook it has actually rehearsed? If yes, Valkey is one more well-understood daemon on hardware you own. If no, the $10 fixed plan is buying you an education you have not paid for yet — take the deal until the meter math says otherwise.

The decision rule​

Count commands first; everything else follows. If you are under 500,000 a month, take the free tier and think about literally anything else. From 500K to ~5 million, pay-as-you-go is the cheapest correct answer — especially for spiky, bursty, or idle-mostly workloads — and the $5 you might save self-hosting is not worth an evening of your life. Past ~5 million steady-state commands, move to the $10 fixed plan; the meter at that volume is a donation. And past the point where your team already operates stateful services confidently, a Valkey on flat-rate hardware you own beats every metered option on price while asking only for the pager discipline you already have.

The deeper lesson generalizes beyond one vendor's pricing page. "Charge by the request, not by the hour" is a genuine innovation for workloads shaped like requests — bursty, idle-able, spiky. It is a trap for workloads shaped like hours — steady, chatty, always-on. Serverless pricing never changed what your workload costs to serve; it only changed which shape of workload gets the good deal. Know your shape, count your commands, and pick the price accordingly.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Flat-rate hardware makes the self-hosted column of every table above your default: star the repo on GitHub or deploy your first app today.