We’ve brought pay-as-you-go pricing to our Upstash Redis extension. This means you only pay for what you use, instead a fixed price per database, just like the rest of the Fly.io platform.
Check the Upstash pricing page for details on how requests and storage are priced.
For those of you running databases already, nothing will change right now. However, you can update your databases to this new plan at any time. The fixed price plans are no longer available.
Note that Upstash will retire the fixed price plans on January 1st, 2024. Meanwhile, they will email you periodically with your usage to help you best choose a plan going forward. You can also track your usage in the Upstash web console.
Also - some of you noticed that tools like Sidekiq and BullMQ poll Redis aggressivelym increasing your Redis request count. Upstash does not count empty Redis responses, so you don’t need to worry about these tools incurring unfair charges.
Sadly, this isn’t quite true. LiteFS Cloud has a $5/mo minimum. Would be great if you added a low/bursty pay-as-you-go option for that like Upstash just did for Redis.
Just FYI: The page transition from the “Visit the Upstash dashboard” in the WebUI (https://fly.io/redis/[NAME]/usage) is broken; the transition from the CLI (fly redis dashboard [ORG NAME]) still works.
Is there a way to see the actual usage that we will be billed for?
Upstash started limiting us on a free tier since we kept hitting 10k request per day. Which shouldn’t happen if they do not count the empty responses.
We upgraded to pay-as-you go and it seems that BullMQ is generating ~10k request per hour. Still haven’t hit 100k requests to see if we are billed for them or not. If we are then having to pay ~15$ just to keep an idle Redis instance alive seems absurd.
EDIT: Looks like we are indeed billed for the whatever empty traffic BullMQ is generating:
Our implementation should be pretty standard (ioredis with bullmq) and the graphs above don’t have any actual data (we tested the integration on Thursday and since then haven’t added a single job to the queue).
At this stage it looks like Upstash is not a suitable provider for us, which is a shame since I really liked the ability to deploy and manage the Redis instance via flyctl.
We are not counting empty requests/responses but unfortunately not all requests from Bullmq are considered empty. Our definition of empty is, any read command returning null (or empty array etc) and any write command not modifying the state.
Even when idle, Bullmq sends some write commands, especially EVALSHA.
I did a test just now, with a single Bullmq queue and a single worker, in 5 minutes period Bullmq sent 445 requests and 335 of them identified as empty and not counted in quota.
I guess this is the main problem - with the help of your replies and having a bit more data the situation becomes somewhat easier to understand.
Yeah, we can actually see that from the dashboard - at the moment there are 600k commands (out of which 30k were generated under free tier) and we are billed for ~190k commands = ~33% of the total.
The ratio seems to be in the same ballpark as to what we are seeing. Although we are seeing ~2x more commands:
Not really sure what is causing the increase though - ideally it should remain the same and not increase 40% overnight.
Either way, assuming it does not keep increasing then I guess it’s not that bad - at ~0.2$ per day per worker it is still much cheaper than any alternative we found.
Hey! Where can I check the number of non-empty requests? The new pricing is kicking in so we would like to have a estimation for the billing too. Not sure if I’m missing out anything from the dashboard. Thanks in advance!
Thank you!
I’m not able to select replica in fra region despite my redis databases are all deployed in fra. Is it expected?
❯ fly redis list
NAME ORG PLAN EVICTION PRIMARY REGION READ REGIONS
adopt personal Free Disabled fra
donate1024 personal 200M Disabled fra
blogigram personal 200M Disabled fra
❯ fly redis update donate1024
Some regions require a paid plan (maa).
See https://fly.io/plans to set up a plan.
? Choose replica regions, or unselect to remove replica regions: [Use arrows to move, space to select, <right> to all, <left> to none, type to filter]
> [ ] Amsterdam, Netherlands (ams)
[ ] Stockholm, Sweden (arn)
[ ] Paris, France (cdg)
[ ] Denver, Colorado (US) (den)
[ ] Dallas, Texas (US) (dfw)
[ ] Secaucus, NJ (US) (ewr)
[ ] Guadalajara, Mexico (gdl)
[ ] Sao Paulo, Brazil (gru)
[ ] Hong Kong, Hong Kong (hkg)
[ ] Ashburn, Virginia (US) (iad)
[ ] Johannesburg, South Africa (jnb)
[ ] Los Angeles, California (US) (lax)
[ ] London, United Kingdom (lhr)
[ ] Madrid, Spain (mad)
[ ] Miami, Florida (US) (mia)
Replicas are for reducing read latency in regions other than the primary. Within a single region, reads are already balanced across multiple instances. Does this help?
