TimescaleDB vs. Amazon Timestream • Hacker News Board

Re: TimescaleDB vs. Amazon Timestream

#201

Post by pezezin » Mon, Dec 07, 2020, 7:53 AM UTC

mfreed wrote: post #184

pezezin wrote: post #177

For me the killer feature of TimescaleDB is that you can run it on your own server. Not all of us can run our services in the cloud. In my case I'm working at a particle accelerator, which is considered a nuclear facility and thus not allowed to be directly connected to the Internet. One year ago I moved our old system to TimescaleDB, and I have been really happy since then, it's a really amazing product. Kudos to th…

Hey pezezin - would love to hear more if you are open to it. Can you ping me at mike @ timescale.com?

Sure, I just sent you an email.

Re: TimescaleDB vs. Amazon Timestream

#202

Post by varjoranta » Sun, Dec 13, 2020, 6:41 AM UTC

BenoitP wrote: post #150

ryanbooz wrote: post #62

Earlier quoted context omitted.

(Disclaimer: post author and Timescale employee) I'm sorry you feel like we were trying to be dishonest in the post. On the contrary, we put a lot of effort (and 7,000+ words) into trying to explain everything that we did - just as we've done with other benchmarks which others have linked to. The TimescaleDB test did not use continuous aggregates for these test, only raw time-series data stored in hypertables. For ea…

Sorry for the harsh comment. I've been reading about your columnar compression pipeline [1], and it sort of makes sense if the comparison is against a regular row-oriented DB. AWS Timestream must really be doing something wrong here, or serving an entirely different use case. 5-175x faster queries and 150x-220x cheaper I do get it. But 6000x higher inserts does not make sense to me. It is insane, and literally unbeli…

Amazon Timestream uses quorum writes as an example.

https://aws.amazon.com/blogs/aws/store-and-access-time-serie...

"This is made possible by the way Timestream is managing data: recent data is kept in memory and historical data is moved to cost-optimized storage based on a retention policy you define. All data is always automatically replicated across multiple availability zones (AZ) in the same AWS region. New data is written to the memory store, where data is replicated across three AZs before returning success of the operation. Data replication is quorum based such that the loss of nodes, or an entire AZ, does not disrupt durability or availability. In addition, data in the memory store is continuously backed up to Amazon Simple Storage Service (S3) as an extra precaution."

Feels like apples to oranges comparison, as the consistency models are really different. Then again, I woul definitely optimize for performance on most timeseries use cases. Different products with different features baked in.

Re: TimescaleDB vs. Amazon Timestream

#203

Post by cpufry » Mon, Dec 14, 2020, 4:00 AM UTC

tester34 wrote: post #11

jpgvm wrote: post #5

Not a surprising result at all. Timestream is another case of AMS trying to make something for the sake of having it (see here Kinesis instead of just doing Kafka and many other products) instead of just adopting something industry standard. That isn't to say they don't do some good stuff just they also ship a lot of crap, very much 2 tiers of products in the AWS catalog. I would eventually like to see comparison for…

Working at AWS must be fun You basically reinvent all the stuff - from databases to all avaliable tooling normal companies dont do that, so there' an opportunity to get deep into some specific branch of applied informatics.

it would be more fun without the annual reinvent death march