3 ms·
> The ratio of writes to reads for your pricing needs to be 100:1 or more for it to make sense for me Correct. I bet Uber’s use case here is something like 100
by bjornsing 2y ago
> The ratio of writes to reads for your pricing needs to be 100:1 or more for it to make sense for me
Correct. I bet Uber’s use case here is something like 1000:1. I’ve worked on systems that were over 1000000:1. That’s where HaystackDB makes sense.
> but I'm more like 10-20:1.
Then RDS is hard to beat.
- erik_seaberg 2y agoYou might be surprised how often a deep graph of microservices ends up rereading the same prior transactions over the course of stateful payment processing and on-demand payouts. DynamoDB can give you 2.6 million short reads of base load (1 RCU/s provisioned) for $0.12 per month, which would make a $65 alternative (2.6 * $5 + 2.6 * $20) a hard sell.
- bjornsing 2y agoTypically you have a “hot-cold” architecture where transactions stay in “hot” storage for a number of days (I think 12 days in the OP if I remember correctly), then are moved to “cold” storage. HaystackDB is primarily designed for the “cold” portion of that architecture. But I am considering adding an open source / source available “frontend” that would provide low-cost “hot” storage.