Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TimescaleDB vs. Amazon Timestream

blog.timescale.com

Post reply on HN
Print view View original

71–80 of 203 posts

Re: TimescaleDB vs. Amazon Timestream

#71

Post by akulkarni »

CodesInChaos wrote: post #69
akulkarni wrote: post #63

Earlier quoted context omitted.

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.

Here you go:

- Community features: All features labeled with "community" on here: https://docs.timescale.com/latest/api. Only restriction is that you can't offer them as part of a Timescale-DBaaS.

- Open-source features: Everything else, licensed under Apache 2

- Enterprise features: No longer exist, we made all of them free/community earlier this year: https://blog.timescale.com/blog/building-open-source-busines...

Hope this helps.

Will pass along the feedback to the team :-)

Re: TimescaleDB vs. Amazon Timestream

#72

Post by CodesInChaos »

akulkarni wrote: post #71
CodesInChaos wrote: post #69

Earlier quoted context omitted.

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.

Here you go: - Community features: All features labeled with "community" on here: https://docs.timescale.com/latest/api . Only restriction is that you can't offer them as part of a Timescale-DBaaS. - Open-source features: Everything else, licensed under Apache 2 - Enterprise features: No longer exist, we made all of them free/community earlier this year: https://blog.timescale.com/blog/building-open-source-busines...…

The documentation still talks about buying an enterprise edition: https://docs.timescale.com/latest/getting-started/exploring-...

Re: TimescaleDB vs. Amazon Timestream

#73

Post by zachd1_618 »

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…

I think AWS is early to offer a not-yet-matured product just to get it in front of customers and start gathering real usage feedback. I’d consider dynamo a fantastic tier 1 service, but it wasn’t always that way. This is inline with the Amazon philosophy in general.

As for “making something for the sake of having it”, I believe the key reason for building their own applications is that they can build it on the same multi-az incremental ledger/block store that underlies most services (first built for aurora), or a variant thereof. They have some pretty stellar underlying tech built to be reliable at cloud scale, something you won’t get from running a service on your own EC2 fleet. The new stuff built on top of it just isn’t all that mature though. That’s just my take though. If interested, the deep dive talk from reinvent last year on aurora is pretty cool.

Disclaimer: I work at Amazon, nothing to do with AWS or timestream. In fact, I’ve been excited for time stream for a while but found its initial performance lackluster for what I needed.

Re: TimescaleDB vs. Amazon Timestream

#74

Post by mfreed »

momothereal wrote: post #68

OT: 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 becau…

You can create a hypertable with a UNIQUE composite key on (row_id, time).

Otherwise, you are correct in that we require your partitioning keys to be at least _part_ of unique constraints; otherwise, we'd need to build global indexes across all your chunks (which would inhibit scalability)...this would only be worse with multi-node =)

Re: TimescaleDB vs. Amazon Timestream

#75

Post by darksaints »

momothereal wrote: post #68

OT: 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 becau…

If row_id is unique, then (row_id,time) is also unique.

Re: TimescaleDB vs. Amazon Timestream

#76

Post by akulkarni »

CodesInChaos wrote: post #72
akulkarni wrote: post #71

Earlier quoted context omitted.

Here you go: - Community features: All features labeled with "community" on here: https://docs.timescale.com/latest/api . Only restriction is that you can't offer them as part of a Timescale-DBaaS. - Open-source features: Everything else, licensed under Apache 2 - Enterprise features: No longer exist, we made all of them free/community earlier this year: https://blog.timescale.com/blog/building-open-source-busines...…

The documentation still talks about buying an enterprise edition: https://docs.timescale.com/latest/getting-started/exploring-...

Aha! We will fix. Thank you.

Re: TimescaleDB vs. Amazon Timestream

#77

Post by ryanbooz »

ahachete wrote: post #70

I 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…

This is a likely option, too. Your observations on pricing are keen.

The one thing that threw me was querying. The limitations felt more Athena-like than PartiQL. And the billing based on scans felt almost like Redshift Spectrum. I mean, S3 is infinitely scalable, right?

It's just impossible to say right now, eh?

Re: TimescaleDB vs. Amazon Timestream

#78

Post by troelsSteegin »

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…

How to tell what service is in what tier, crap or good? What's the metric? I am not a direct user of AWS, so absent an informed technical judgment of "this is a deployment and renaming of that", eg Kinesis for Kafka, how do you know what to avoid? In general, it seems like the value-add for service X is that now that function is integrated to some degree w/ the rest of AWS - so maybe it's based on effective feature set/use cases plus integration points. Alternatively, some function of throughput and unit cost.

If I were a SAAS competing with an AWS service, I would want to know how long before a given AWS service might get good enough to be an alternative for my customers. If you run with the idea that AWS offerings get better over time and eventually cross some threshold of "not good" to "good", maybe a crawl of the AWS announcements[0] in combination with a metric could provide a predictor of an AWS service's time to "good"...

[0] https://aws.amazon.com/new/

Re: TimescaleDB vs. Amazon Timestream

#79

Post by SmokeyHamster »

eloff wrote: post #57

If you take one thing away from this it's do not use AWS timestream, and if you are using it, get rid of it quick. It's unfit for purpose. That first graph tells you everything you need to know. Time to insert a billion events: TimescaleDB: 5 min AWS Timestream: ~2 weeks! I think the team at AWS that built it should be reassigned and contractors or an A team brought in to try and salvage it. Because they've built the…

Yeah, differences like that are why I ditched MySQL years ago in favor of PostgreSQL.

I was using MySQL at the time, and did a performance comparison of how long it took each database to dump and load a snapshot of a 100GB database.

MySQL took 3 days.

PostgreSQL took 30 minutes.

I posted on a MySQL forum asking why the drastic difference, and they tried to hand-wave it away by saying I had a lot of indexes. Well yeah, databases have indexes. I shouldn't expect my MySQL database transfers to be quick if it has an index? Features shouldn't cripple the application for routine tasks.

Re: TimescaleDB vs. Amazon Timestream

#80

Post by dash2 »

LukeEF wrote: post #41
tester34 wrote: post #11

Earlier quoted context omitted.

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.

But why do they do it so badly? Seems like they have the engineering muscle to put out a great reinvention of a document db, a time series db, a graph db... but each is relatively poor to the other services on AWS. Is it the combination of MVP-culture and lock-in?

The article suggests an answer:

"The viability of our company, Timescale, is 100% dependent on the quality of TimescaleDB. If we build a sub-par product, we cease to exist. Amazon Timestream is just another of the 200+ services that Amazon is developing. Regardless of the quality of Amazon Timestream, that team will still be supported by the rest of Amazon’s business – and if the product gets shut down, that team will find homes elsewhere within the larger company."

Post reply on HN