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

41–50 of 203 posts

Re: TimescaleDB vs. Amazon Timestream

#41

Post by LukeEF »

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.

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?

Re: TimescaleDB vs. Amazon Timestream

#42

Post by xyst »

What an embarrassment for AWS - getting smoked by an open source project. Should just fire the management team overseeing the timestream project and just provide managed timescaledb instances.

Re: TimescaleDB vs. Amazon Timestream

#43

Post by oblio »

rattray wrote: post #21

Full title includes a summary of benchmark results for the lazy: Timescaledb achieved 6000x higher inserts, 5-175x faster queries, 150x-220x cheaper Benchmarks open-source, methodology in post.

If I were them I wouldn't rest on my laurels. v1 from AWS is an MVP. It will keep getting improved.

I'd like to see those numbers 2-3 years from now.

Re: TimescaleDB vs. Amazon Timestream

#44

Post by mfreed »

intellix wrote: post #38

Dying to use this on Google Cloud SQL but they just won't support the extension. There's an issue with upvotes to add support but still no official response as to whether support is coming... extremely frustrating

Although even if Google were to add support for TimescaleDB, it would only be for the Apache-2 version of the database, which lacks many of its key features (compression, continuous aggregates, multi-node scale out, data retention policies, job scheduling framework, various analytical functions, etc.)

See this HN discussion about Timescale's "cloud protection" licensing [0].

Of course, Timescale Cloud is available across 20+ GCP regions =)

[0] https://news.ycombinator.com/item?id=24579905

Re: TimescaleDB vs. Amazon Timestream

#45

Post by nkozyra »

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?

Breadth versus depth seems to be the play outside of their absolute core offerings. It allows people to dip their toes into something with minimal commitment and by the time they realize the shortcomings they might conclude that migrating for those features just isn't worth it.

So this give them a bit of lock-in. Come for the EC2, stay for the minimally viable queues, machine learning, containers, etc.

Re: TimescaleDB vs. Amazon Timestream

#46

Post by ants_a »

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 and single threaded compression. If InfluxDBs measurement oriented data model and query interface is a good fit for your use case, and you don't have high cardinality data, then it might be convenient to use it, but it's a terrible choice for anything outside its niche.

However none of the databases tested above is anywhere close to the efficiency of a column store database that can do vectorized execution over batches of rows. ClickHouse is a good example of one such database. For queries that have to shift through large amounts of data, either filtering or aggregating it, the performance difference is easily >10x. I was seeing aggregation performance above 2B rows/s and that was I/O throughput bound.

Re: TimescaleDB vs. Amazon Timestream

#48

Post by BenoitP »

Pre-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 the source though [1].

TimescaleDB is probably a very good product (and pg-compatible!), but producing such articles hiding the usage of a magic feature is sort of dishonest. Why not make an article directly on the power of the feature? It's hurting their brand reputation a bit.

[1] https://github.com/timescale/tsbs

Re: TimescaleDB vs. Amazon Timestream

#49

Post by that_guy_iain »

Aeolun wrote: post #16
that_guy_iain wrote: post #7

Earlier quoted context omitted.

It seems like AWS is just focusing on increasing it's vendor lock in and it makes sense not just from the AWS point of view but if you're a developer at an enterprise company that has authorised AWS the more databases the clone, poorly or badly the more choice you have without having to get authorisation and the cost doesn't matter to the developer since the enterprise company is paying for it. I suspect there are ma…

But you can just run timescaleDB inside your amazon VPC. No need to use their services at all.

You can but then you need to spend time setting up and maintaining the service. Which many enterprises aren't willing to do. Also, while you may be authorised to use AWS tech you may not be automatically authorised to use different tech. We literally were told to use MySQL instead of MongoDB soley because RDS was allowed and all services had to be managed by AWS.

I am not complaining AWS is doing vendor lock in makes complete sense, I am just commenting that is their main direction for their offering. And their vendor lock is aimed at the enterprises where they can really run wild on it and get lots of money in return. Smaller orginisations will generally never lock themselves in so much because they won't build so many things that are so hard coupled since they just don't have the manpower.

Re: TimescaleDB vs. Amazon Timestream

#50

Post by webo »

intellix wrote: post #38

Dying to use this on Google Cloud SQL but they just won't support the extension. There's an issue with upvotes to add support but still no official response as to whether support is coming... extremely frustrating

Curious why not use Timescale Cloud?
Post reply on HN