This series started partly as a cost question. The Postgres-first design was chosen for correctness, but the reason I could even consider it was that it looked cheaper. This post checks that: what does the stack cost on managed cloud, and where does the money actually go?
Prices below are list rates, illustrative, for a small workload of a few million events a month growing to ten million. Verify on the provider calculators before you budget. The point is not the exact dollar, it is the shape.
The one lever that dominates everything
At this scale, cost is set by the always-on minimum of each managed service, not by usage. And one lever swamps the rest.
The Redis persistence tier is the biggest lever: premium with persistence is roughly eight times the standard highly available tier, and this design never needs it
On one major cloud, Redis persistence only unlocks on a premium tier at roughly eight times the price of the standard highly-available tier. That is the single biggest number in the whole budget. And here is the satisfying part: because this design makes Redis a transient transport that holds no durable truth, we never need persistence, so we never pay for that tier. A decision made purely for correctness removed the largest line item for free.
The second lever is the database instance size and high availability: a highly-available (multi-zone) database roughly doubles the compute cost. Right-size there before anything else, and add HA only when the service genuinely needs it.
What we are pricing
Three managed pieces, plus one you may already run:
- Postgres, the source of truth. Small data, growing.
- Redis / Valkey, the transient live-view transport. No persistence, so the cheap tier.
- Container compute, for the API and the tiny relay worker (which can scale to zero).
- An event stream for the telemetry lane, often already in place, so treated as sunk.
AWS versus Azure, briefly
I priced a comfortable production stack on both major clouds. The interesting result is how close they are.
| Stack | AWS | Azure |
|---|---|---|
| Lean start | ~$47 / mo | ~$42 / mo |
| Comfortable prod (HA DB, HA Redis, 2 API instances) | ~$174 / mo | ~$177 / mo |
They land within a few dollars at both tiers. So price does not decide between the clouds. Locality does. If your event stream already runs on one cloud, keep the database and Redis next to it, because splitting them across clouds puts a cross-cloud network hop (tens of milliseconds) on your live path for no dollar saving. The egress cost of that split is trivial (a few dollars a month); the latency is the real tax.
The recommended stack
Stay on one cloud, next to the eventing you already run, right-sized, with the persistence lever off so Redis stays cheap.
Recommended stack: container compute, Postgres as truth, a cheap non-persistent managed Redis, and the existing event stream, roughly fifty to one hundred fifty dollars a month
- Postgres (managed Flexible Server): from a small burstable instance to a highly-available one as you grow.
- Managed Redis, cheapest tier, no persistence, HA on. It holds nothing durable, so a crash just re-hydrates from Postgres.
- Container compute for the API, with the relay scaling to zero.
- The event stream, existing, sunk.
That lands at roughly $52 a month to start and about $150 a month with full HA, both far under a typical target. Against a legacy bill several times that, it is a large, boring win.
The part I find satisfying
The choice that made this cheap was not a cost optimization. It was the correctness decision from part one: Postgres owns the truth, Redis is disposable. The cheap bill fell out of it. When the most correct, most robust, and cheapest option turn out to be the same option, take it and do not get clever.
The caveat, again
These are still planning numbers, not a bill, and they are for the resources in isolation. The final part of this series is the real cloud deployment, where I stand the whole thing up on managed Postgres and Redis and measure both the actual cost and the actual end-to-end latency, network included. Everything before it, including this post, is the estimate. That one is the receipt.