4 ms·
> 224x cheaper if you’re self-managing TimescaleDB on a VM I'm having a hard time understanding the cost comparison without details of the above. Are they sayi
by crescentfresh 6y ago
> 224x cheaper if you’re self-managing TimescaleDB on a VM
I'm having a hard time understanding the cost comparison without details of the above. Are they saying that hosting your own cluster of timescaledb nodes within EC2 still comes in cheaper than timestream? This seems impossible, depending on the instance types of course.
- detaro 6y agoWhy does that seem impossible?
- deepstack 6y agoif you self-host is always cheaper than using AWS. It also keep you not have to lock down to a vendor. AWS use to be great when it first came out in 2006ish, but now it is just because a pain to work with. EDIT: especially considering all the other options are available in VPS now days.
- crescentfresh 6y agoThis depends on what AWS service we're talking about, doesn't it? For example a Kinesis stream compared to running a (say) 5 EC2 node Kafka cluster with zookeeper etc. Isn't it within the realm of possibility the managed service comes out cheaper?
- ryanbooz 6y ago(Disclaimer: blog author and Timescale employee) There are two main points here. 1. To complete this benchmark workload, it took less than an hour in two different environments (Digital Ocean self-managed & Timescale Forge fully managed) to ingest 1 billion metrics and run all 30K queries. It took us a week of work (testing, modifying code to try and make Timestream better) to get 40% of the metrics into Timestream and then query it. 1 hour vs 7 days. 2. If you look at the bill/costs, the main driver was querying. We (attempted) to run the same 30K queries on less than half the data (410 million metrics) in Timestream and somehow scanned 21TB of data. I have no idea why and there's nothing we could do to change it. As a developer, that's going to be your biggest unknown. If you're ingesting millions or billions of metrics a day and querying it with a real application, you could really get hit with crazy query costs. With a more traditional server architecture, at least you know your day-to-day costs and can set a known capacity to achieve the performance you need (or scale in understandable ways when you need it)