Does timescale have a page giving a clear overview of the different offerings/editions and their features and limitations?
TimescaleDB vs. Amazon Timestream
61–70 of 203 posts
Re: TimescaleDB vs. Amazon Timestream
#62Pre-reading hypothesis: TimescaleDB is declared orders of magnitude faster because the benchmark is serving results they're computing at writing time? Is it just like the ClickHouse benchmark from earlier, where they read from a `CREATE TABLE [...] ENGINE = AggregatingMergeTree`? Post-reading: "faster queries via continuous aggregates". So is this it? I couldn't find how tables / materialized views were created in th…
(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 each database, we (and other contributors) do our best to use features in all cases that take advantage of the DB. For TimescaleDB, a function like LAST() happens to be really powerful for most workloads and is really, really fast. That's not cheating, it's using the software properly! :-)
The SQL that we generate for each database can be examined here (https://github.com/timescale/tsbs/tree/master/cmd/tsbs_gener...) and as an open source project, anyone is free to contribute!
Re: TimescaleDB vs. Amazon Timestream
#63Does timescale have a page giving a clear overview of the different offerings/editions and their features and limitations?
Were you looking for something like this?
Re: TimescaleDB vs. Amazon Timestream
#64Earlier quoted context omitted.
Depends on what type service you trying.... We do face few hiccups now and then.. but overall okay.. Rather i would recommend to go with architecture that is not tightly coupled to certain vendor and built on open source products... We also prefer/buy services from companies who build OSS like in case of ELK, we, rather than hosting and doing it by ourselves. We are more than happy to pay bit more for hard work their…
That is not the mantra at our company. We want serverless and managed services whenever possible because getting resources to setup and maintain anything is next to impossible. We are now trying to use some competing products to AWS products that are full SaaS, so theoretically great, but because it isn't tacked on to our AWS bill it is very hard to get it approved and we are waiting around for weeks turning into mon…
I'm not saying you should not! But lets just say you want ELK stack, you can try ELK cloud from Elastic which is hosted on AWS or Azure Or GCP as managed services But Elastic company manages it...That also help those folks support themselves.
Re: TimescaleDB vs. Amazon Timestream
#65Not 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.
Sometimes I'm not even sure they're re-inventing, just adding a vender-lock-in layer on top of the service and making it run on Lambda so they can advertise it as "web-scale".
Re: TimescaleDB vs. Amazon Timestream
#66AWS is no longer our friend. We need to start weening ourselves from them. They are literally just looking at a list everyday and saying, what company can we try to screw over today.
That's so true. For big corps thats just game of money, a channel for more revenue and VP of products to shine/brag about it in next quarterly meeting.
Re: TimescaleDB vs. Amazon Timestream
#67AWS is no longer our friend. We need to start weening ourselves from them. They are literally just looking at a list everyday and saying, what company can we try to screw over today.
That's so true. For big corps thats just game of money, a channel for more revenue and VP of products to shine/brag about it in next quarterly meeting.
Its not that, its fine for there to be big corps, and for companies to play the game and get money. Its the way that amazon choses to play the game. They are unsportsmanlike, and sometimes downright cheaters.
Re: TimescaleDB vs. Amazon Timestream
#68OT: Every time I see Timescale on here I'm excited to use it. After some preliminary testing I always run into the same issue: can't create a hypertable if there's a unique index / primary key that doesn't include the 'time' field.
For example my data looks like (row_id, user_id, time, data), where row_id is a unique ID, and time is a non-unique time field. Timescale will refuse to create a hypertable like this because it causes partition issues.
Re: TimescaleDB vs. Amazon Timestream
#69Does timescale have a page giving a clear overview of the different offerings/editions and their features and limitations?
Were you looking for something like this? https://www.timescale.com/products
This page misses several editions mentioned in other places (at least enterprise and open-source, perhaps more?).
It also doesn't mention which license limitations the "community" edition has, I only found a blog post talking about them https://blog.timescale.com/blog/building-open-source-busines....
I would have expected one place which compares all available options.
Re: TimescaleDB vs. Amazon Timestream
#70I enjoy trying to guess how cloud services like Amazon Timestream are internally built. I have already bet in the past that DocumentDB was built on top of (Aurora) PostgreSQL (this I also know was possible as I founded https://torodb.com).
My bet for Timestream is that is built on top of DynamoDB. There are many potential indicators (1KB writes, throttling) and some clear ones(pricing follows the exact proportion up to the 4th decimal if you compare across regions, for example), it supports "unlimited" scalability, batching, etc. That reads are eventually consistent may be because they are computed over a GSI. It would be interesting if true as it is cheaper for writes than DynamoDB (on demand, which is the model Timestream has).
Plus there is a reasonable amount of mindshare and possibly market opportunity into offering time series on a serverless database like DynamoDB.
If this were true, it would also mean that Timestream, as hinted in the post, is more performant when accessed more in parallel (as DynamoDB itself is by design a massively parallel multi-tenant infrastructure).