4 ms·
Yeah, read and write request pricing is still the big unanswered question here. It’s great that they are happy to have a free tier, but <10RPS is only <777k pe
by kondro 5y ago
Yeah, read and write request pricing is still the big unanswered question here.
It’s great that they are happy to have a free tier, but <10RPS is only <777k per day constant. Great for small uses, but pretty easy to hit with even medium object store use-cases.
My current guess would be somewhere around S3’s $5/million writes and $0.40/million reads (with maybe a 20% discount like they’ve done with other products). Hope I’m wrong and it’s a lot lower though.
I’m probably in the minority, but I want to use an object store like this as a key/value store for <128KiB objects (write once, read a handful of times and then expire in 14-90 days).
I’d gladly pay egress, but usually the request prices (for S3 or DynamoDB) become pretty cost-prohibitive. Even services like Wasabi that, on the face of it look perfect, end up being unsuitable because the T&Cs limit maximum egress to total monthly storage volume (making the write once, read more than once for every short-lived object pretty difficult).
I’d gladly pay for a service with both “reasonable” egress and “reasonable” request prices instead of everyone trying to weight their service to one or the other.
- babelfish 5y agoCheck out Cloudflare Workers KV or Durable Objects :-)
- kondro 5y agoSorry, should've specifically mentioned them. Workers KV is also $5/million writes and $0.50/million reads[1] (more expensive than S3 which is $0.40/million reads) and often DynamoDB (which is $1.25/million 1KB writes and $0.25/million reads scaling down to 1/7th that if you use provisioned instead of on-demand). Workers KV is also eventually-consistent with no guarantee of read-after-write, which is a pretty big limitation compared to alternatives (S3 even has immediately-consistent list operations now after write). Durable Objects Storage is $1/million writes at 4KB and $0.20/million reads[2], which is pretty good. But you can also only access it via a Durable Object which limits its usage (especially as neither Durable Objects or its storage are in a production state with final pricing yet) and means you need to also pay for the Durable Object runtime on top fo the Storage pricing whenever you want to access that data. [1] https://developers.cloudflare.com/workers/platform/pricing#paid-plan-1 https://developers.cloudflare.com/workers/platform/pricing#p... [2] https://blog.cloudflare.com/durable-objects-open-beta/ https://blog.cloudflare.com/durable-objects-open-beta/
- londons_explore 5y ago> But you can also only access it via a Durable Object which limits its usage Presumably with not-a-lot of code you could write a Durable Object to have an S3 compatible API...
- kondro 5y agoIt wasn't the code that was the issue (and you probably wouldn't want an S3 compatible API). It's that on top of the Durable Store pricing, you need to pay for the $0.15/million requests + $12.50/million GB-sec processing + $0.09/GB data transfer. Given the point of R2, the fact there's $0.045/GB ingress + egress data transfer (which has been recently reduced from $0.09) when using Durable Objects. Given the original comment is basically about egress being too expensive therefore R2 is offering to for free, Durable Objects' Store isn't a particularly good alternative to just using S3 or DynamoDB unless you're already using Workers/Durable Objects.
- qeternity 5y agoOut of curiosity what is your use case? What is S3 latency compared to Dynamo?
- kondro 5y agoPretty similar really. Latency is much less important than throughput for all of my use-cases.
- Something1234 5y agoAnd why doesn't something like dynamo work perfectly for this?
- kondro 5y agoI love DynamoDB for a lot of things, but as a store for objects much larger than 1KiB it's not very cost-effective. DynamoDB writes are priced per WCU. A WCU will give you 1KiB written to the DB. In On Demand, WCUs cost you (depending on region) $1.25/million writes. For Provisioned capacity, you pay about 1/7th that (but need to deal with keeping the Provisioned capacity and auto-scaler at the correct level, so in practice you can maybe get this to about 25-35% the On Demand rate when you know what your usage looks like, with further discounts for actually reserving capacity). If you're writing 32KiB objects, this uses 32x WCU ($40/million writes) and if these objects are even updated (e.g. to change a status or similar), the update writes the entire object again. On a performance/architecture note, DynamoDB has a hard per-partition limit of 1,000 WCU (per second). Writing larger objects can very quickly get you to these limits which increase your architectural complexity by requiring you to shard access. Although, in practice you'd never write large objects to DDB. S3 is _only_ $5/million writes (and $0.023/GB/month vs $0.25/GB/month for DDB). If you're writing even 3+ KB (especially if you expect to need to update an item in the future) it's usually more cost effective to store these blobs in S3. But either way, you're still going to be paying at least $5/million write requests. For multi-MB blobs, this is a non-issue. But for a K/V store of smallish objects, I think it's pretty expensive.
- londons_explore 5y agoI really want to not need to care about object sizes. Whether I'm writing 1 byte or 1 gigabyte, I want to have the same semantics, same API, and same sane billing model. The underlying tech can differ depending on object size, but as a user, I want it to all transparently look like one unified store.
- kondro 5y agoMe too… but I don't think anything really does this. _Maybe_ Firebase Store for certain scenarios, but it has its own tradeoffs too.
- renewiltord 5y agoI just stored a few large objects to pad the space on Wasabi. The S3 compatibility was the feature.