TimescaleDB vs. Amazon Timestream

Post by valyala » Sat, Dec 05, 2020, 3:04 PM UTC

jpgvm wrote: post #30

atanasovskib wrote: post #10

Earlier quoted context omitted.

In my opinion it would be very hard to justify using Timestream for any analysis heavy workloads for at least three reasons: 1. Queries will need to touch a lot of data - will cost a lot, and there is no ability to optimize the queries in any way (no EXPLAIN, no indexes, no downsampling) 2. No integration with data exploration and visualization tools 3. No ability to have non-timeseries data, or correlate any data in…

I completely agree I think you misunderstood me. I would like to see comparisons between Timescale and Druid. I already know Timestream isn't up to the task lol.

Post by valyala » Sat, Dec 05, 2020, 3:12 PM UTC

ants_a wrote: post #46

hardwaresofton wrote: post #17

I'm very towards Postgres and resultingly Timescale for being one of it's biggest shining stars. Combine that with a cynical view that this is essentially S-tier content marketing (in the tech world), and the numbers are still bonkers. Might as well add on a bit here -- if you're into this sort of thing you might enjoy Timescale thrashing other purpose-built databases (which have since also improved so YMMV): - Times…

I did some time series data benchmarking recently. Most large data is "time series" data, but I will not digress on terminology right now. For the usecase I was looking at my results for InfluxDB did not qualitatively disagree the above blogpost. Timescale got better compression efficiency, faster query results, more constrained memory usage, but lower ingest speed at high concurrencies blocked by WAL insert locking…

Post by valyala » Sat, Dec 05, 2020, 3:34 PM UTC

nwsm wrote: post #89

On topic: While the comparison seems terrible for Timestream, as a customer who does not want to manage my databases I would love a similar GCP option, if the product had better tradeoffs. It's also interesting that Timescale attributes this AWS product to their own licensing. They had some much discussed [0] developments on that front, and if it did in fact force AWS to build their own implementation, that seems lik…

Post by hagen1778 » Sat, Dec 05, 2020, 3:44 PM UTC

valyala wrote: post #192

hardwaresofton wrote: post #17

I'm very towards Postgres and resultingly Timescale for being one of it's biggest shining stars. Combine that with a cynical view that this is essentially S-tier content marketing (in the tech world), and the numbers are still bonkers. Might as well add on a bit here -- if you're into this sort of thing you might enjoy Timescale thrashing other purpose-built databases (which have since also improved so YMMV): - Times…

See also VictoriaMetrics vs TimescaleDB vs InfluxDB benchmarks: - https://valyala.medium.com/measuring-vertical-scalability-fo... - https://valyala.medium.com/when-size-matters-benchmarking-vi... - https://valyala.medium.com/high-cardinality-tsdb-benchmarks-...

Post by pezezin » Mon, Dec 07, 2020, 12:14 AM UTC

valyala wrote: post #194

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…

Do you work on CMS project at CERN? As I know, they successfully use VictoriaMetrics for collecting and analyzing monitoring data. See https://indico.cern.ch/event/877333/contributions/3696707/at... and https://arxiv.org/pdf/2007.03630.pdf .