18 ms·

TimescaleDB vs. Amazon Timestream

• crescentfresh 6y ago
  > 224x cheaper if you’re self-managing TimescaleDB on a VM I'm having a hard time understanding the cost comparison without details of the above. Are they saying that hosting your own cluster of timescaledb nodes within EC2 still comes in cheaper than timestream? This seems impossible, depending on the instance types of course.
  • detaro 6y ago
    Why does that seem impossible?
  • deepstack 6y ago
    if you self-host is always cheaper than using AWS. It also keep you not have to lock down to a vendor. AWS use to be great when it first came out in 2006ish, but now it is just because a pain to work with. EDIT: especially considering all the other options are available in VPS now days.
    • crescentfresh 6y ago
      This depends on what AWS service we're talking about, doesn't it? For example a Kinesis stream compared to running a (say) 5 EC2 node Kafka cluster with zookeeper etc. Isn't it within the realm of possibility the managed service comes out cheaper?
  • ryanbooz 6y ago
    (Disclaimer: blog author and Timescale employee) There are two main points here. 1. To complete this benchmark workload, it took less than an hour in two different environments (Digital Ocean self-managed & Timescale Forge fully managed) to ingest 1 billion metrics and run all 30K queries. It took us a week of work (testing, modifying code to try and make Timestream better) to get 40% of the metrics into Timestream and then query it. 1 hour vs 7 days. 2. If you look at the bill/costs, the main driver was querying. We (attempted) to run the same 30K queries on less than half the data (410 million metrics) in Timestream and somehow scanned 21TB of data. I have no idea why and there's nothing we could do to change it. As a developer, that's going to be your biggest unknown. If you're ingesting millions or billions of metrics a day and querying it with a real application, you could really get hit with crazy query costs. With a more traditional server architecture, at least you know your day-to-day costs and can set a known capacity to achieve the performance you need (or scale in understandable ways when you need it)
• ishikawa 6y ago
  That is an interesting test I wanted to see for some time. When Timestream came out I was a bit surprised by its price. It might work well for Enterprise POC but for larger use the cost benefit is not appealing.
• gnur 6y ago
  Did not expect these results, has anyone done similar tests with other timeseries databases?
  • atanasovskib 6y ago
    The blog post links to a comparison done by the CrateDB folks (https://crate.io/a/amazon-timestream-first-impressions/ https://crate.io/a/amazon-timestream-first-impressions/)
• jpgvm 6y ago
  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 a more analysis heavy workload vs Druid though. Simple metrics workloads like what Timestream and Influx do aren't really of interest when comparing to Timescale ability to do JOINs and use other SQL and PostgreSQL specific functionality.
  • that_guy_iain 6y ago
    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 many enterprises that are already so locked into AWS that it would take them a decade to move to a different provider.
    • frankietaylr 6y ago
      I don't have much expertise with Timestream. Can't comment on it. But, there is nothing wrong in trying for an alternate implementation. We're using Kinesis and it is a good fit in our stack with lot less overhead. They did bring Kakfa (Amazon MSK) later to the AWS service list. Its upto the consumer to pick Kinesis or MSK. One example which was influential in nature - Dyanmodb. The Dyanmodb paper inspired a number of NoSQL databases, including Apache Cassandra. If they have went with the popular NoSQL database at that time, we might have missed some good contribution.
    • Aeolun 6y ago
      But you can just run timescaleDB inside your amazon VPC. No need to use their services at all.
• ronlobo 6y ago
  Timescale is what you want to go with in case of RDMSes with audibility in terms of change management over time. It is the THING. Thanks the timescale team for making this happening!
• mpsq 6y ago
  I can't get over the fact that they first say: "Amazon has a history of offering services that take advantage of the R&D efforts of others: for example, Amazon Elasticsearch Service, Amazon Managed Streaming for Apache Kafka,[...]" And at the end of the article they promote how they themselves rely on other people hard work: "TimescaleDB uses a dramatically different design principle: build on PostgreSQL. As noted previously, this allows TimescaleDB to inherit over 25 years of dedicated engineering effort that the entire PostgreSQL community has done to build a rock-solid database that supports millions of applications worldwide." In the end, it sounds like they are doing exactly what Amazon is doing with open-source.
  • rattray 6y ago
    Except timescaledb is open source: https://github.com/timescale/timescaledb https://github.com/timescale/timescaledb
    • mpsq 6y ago
      This GitHub repository is just the database, what about the code that holds together their cloud resources? I was not able to find it. They criticize AWS for making money on Elasticsearch for example, AWS is "taking advantage of the R&D efforts of others". So Amazon is making money on a "serverless" / cloud experience. At the same time, it is known that Amazon is contributing back to Elasticsearch [1]. To that regard, I find their business model really similar to the one AWS is relying upon. [1] https://www.techrepublic.com/article/aws-contributes-to-elasticsearch-and-critics-say-its-kneecapping-competitors/ https://www.techrepublic.com/article/aws-contributes-to-elas...
      • rattray 6y ago
        Huh? If I want to run someone else's software on my cloud, how I want to do that depends on my cloud. I want docs and binaries, not a full cloud configuration. Some people would want k8s, some docker swarm or whatever, some an aws config, others ansible, etc etc etc. If I want a managed service, I _want_ to pay for that. The price includes people responding to pages and fixing problems, as well as fiddling with configs. And I'd much rather be paying that money to a small (relatively) open-source company than a behemoth like AWS.
• hardwaresofton 6y ago
  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): - Timescale vs Influx[0] - Timescale vs Mongo[1] - Timescale vs Cassandra[2] These blog posts are all from the timescale side, but the numbers are undeniable and their methodology is open source -- not sure there's more you can ask. Cassandra probably scales better at FB/Twitter scale, but with the recent work done to improve Timescale's scaling features[3] and the permissive license (unless you're an Amazon) I'm not sure even that is a real benefit. I'd love to see a response from Amazon -- if HN is so lucky to have a dev who worked on AWS Timestream that would be awesome. [0]: https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/ https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-... [1]: https://blog.timescale.com/blog/how-to-store-time-series-data-mongodb-vs-timescaledb-postgresql-a73939734016/ https://blog.timescale.com/blog/how-to-store-time-series-dat... [2]: https://blog.timescale.com/blog/time-series-data-cassandra-vs-timescaledb-postgresql-7c2cc50a89ce/ https://blog.timescale.com/blog/time-series-data-cassandra-v... [3]: https://blog.timescale.com/blog/timescaledb-2-0-a-multi-node-petabyte-scale-completely-free-relational-database-for-time-series/ https://blog.timescale.com/blog/timescaledb-2-0-a-multi-node...
  • ryanbooz 6y ago
    We've made every effort to be open about all of the testing we do and many people outside of Timescale contribute to TSBS. As an aside, we tried to solicit help/feedback on both Twitter and Redit groups. One AWS employee reached out and offered to pass it to the team (I was upfront about what we were doing) - but we never heard back.
  • ants_a 6y ago
    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.
• rattray 6y ago
  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.
  • oblio 6y ago
    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.
    • dannyw 6y ago
      I'd also shout as widely as possible why their product is better to limit the traction AWS's offering gets.
    • avthar 6y ago
      Timescale employee here. We generally update our benchmark blogs every year to keep them fresh. No doubt you'll see the updated results here on HN as well!
  • daenney 6y ago
    Yup, I would've kept it in the submission except the full title is 16 characters too long for the HN Title field. It felt weird to only include part of it, so I just chopped all of it off.
    • rattray 6y ago
      Oh yeah sorry - didn't intend as a criticism! I think the hn headline should be concise, what you have was perfect. _Maybe_ adding the word "benchmarks" could have clarified but you cover more than that in the post.
• rattray 6y ago
  My takeaway from this is more to be wary of AWS than anything. I've also heard gcp can be a real mess. Is Azure any good yet?
  • ameyv 6y ago
    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 team has done.
    • dumbfounder 6y ago
      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 months.
      • ameyv 6y ago
        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.
        • dumbfounder 6y ago
          Hosted on AWS does not mean it gets wrapped up in the AWS bill. Which means we need to sign a separate contract, which is painful to make happen.
  • mcqueenjordan 6y ago
• rattray 6y ago
  Under what circumstances would TimescaleDB be a poor choice for a company already using postgres at this point?
  • baq 6y ago
    the biggest pain i've got with my postgres instances is upgrading them, and that's without pretty much any storage backend extensions. i imagine using any extension is only going to make it harder to do.
• nhourcard 6y ago
  Thank you for posting this benchmark, great addition to the TSDB community. We look forward to benchmarking our SQL time-series database QuestDB[1] versus both using the TSBS framework soon! [1] https://questdb.io/ https://questdb.io/
  • 120bits 6y ago
    select * from trips where tip_amount > 500 ORDER By tip_amount DESC 65 rows in 80.31s Execute:80.16s Network:144ms Total:80.31s Is this the fastest? Or having a <5ms would have a huge impact?
• intellix 6y ago
  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
  • mfreed 6y ago
    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 https://news.ycombinator.com/item?id=24579905
    • intellix 6y ago
      It all looks amazing and I want it but am personally quite weak at Database administration. I think I'll have to wait until there's a guide which allows me to migrate from a 9.6 Cloud SQL instance to TimescaleDB Cloud without any downtime. I'm doing a quick google for "Cloud SQL migrate to Timescale". There's a guide from Google themselves but it's not without downtime. I read that you can't easily migrate 9.6 to another version of PG via streaming replication until 10 :(
  • webo 6y ago
    Curious why not use Timescale Cloud?
  • davidgl 6y ago
    Azure support Timescale in their PasS - https://azure.microsoft.com/en-us/blog/power-iot-and-time-series-workloads-with-timescaledb-for-azure-database-for-postgresql/ https://azure.microsoft.com/en-us/blog/power-iot-and-time-se...
    • ryanbooz 6y ago
• TheGuyWhoCodes 6y ago
  Not to mention that Timestream inserts time range are dependent on the memory store configuration (https://aws.amazon.com/timestream/faq/ https://aws.amazon.com/timestream/faq/), so if you need to insert data past that configuration it's a PITA.
• xyst 6y ago
  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.
  • ctvo 6y ago
    Unfortunately that company will double down even if there's a hint of traction, and in 3 years it'll finally be decent and TimescaleDB's cloud offering will be in trouble. They have a lot of money and a bit of time. It is very embarrassing that Timestream was delayed for so long only to lose so badly.
  • daenney 6y ago
    A decent amount of AWS product offerings get smoked by FLOSS counterparts. But being able to 1-click use something, not having to figure out how to deploy it, potentially getting commercial support for it etc. is awfully tempting even if the product is only 1/3rd as good.
• nautilus12 6y ago
  AWS 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.
  • ameyv 6y ago
    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.
    • nautilus12 6y ago
      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.
• BenoitP 6y ago
  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 https://github.com/timescale/tsbs
  • eloff 6y ago
    This comment is pretty dishonest after reading the article. The most striking part of the benchmarks was the absurdly abysmal insert rate for timestream. Honestly after seeing that, 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 themselves a very expensive lemon and they're trying to sell it to the world as a Cadillac.
  • ryanbooz 6y ago
    (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_generate_queries/databases https://github.com/timescale/tsbs/tree/master/cmd/tsbs_gener...) and as an open source project, anyone is free to contribute!
    • 6y ago
• eloff 6y ago
  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 themselves a very expensive lemon and they're trying to sell it to the world as a Cadillac. The fact that they did not detect this themselves before or since releasing it upon the world demonstrates to me that they're incompetent and have to be replaced.
  • SmokeyHamster 6y ago
    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.
    • eloff 6y ago
      That's surprising to me since Postgres does less efficient writes compared to MySQL in order to optimize for read queries[1] - a sensible tradeoff since most of the time reads are more common than writes in OLTP workloads. TimescaleDB essentially solves this problem for the specific case of time-series inserts. [In Postgres] if we have a table with a dozen indexes defined on it, an update to a field that is only covered by a single index must be propagated into all 12 indexes to reflect the ctid for the new row.[1] [1] https://eng.uber.com/postgres-to-mysql-migration/ https://eng.uber.com/postgres-to-mysql-migration/
      • aforwardslash 6y ago
        The parent post didn't have enough detail, but I'd assume the dump would be using COPY for inserts. AFAIK when using COPY, the indexes are only built at the end of the command, not on each insert.
• nautilus12 6y ago
  It doesn't matter, look at kinesis. People are willing to use it over kafka (even though AWS has a hosted kafka solution), just because the percieved convenience and interconnectivity to other AWS services. If timescale starts to make serious money, then AWS can use this to mobilize their engineering and make it fast and take timescale out. Amazon's goal is literally to be the only kid on the block for everything forever. Normally that kind of competition would be good, but they are wiling to cut the price so low and take massive loses for really long periods of time until all the competition dies out. Which isn't honest competition.
  • sradman 6y ago
    Amazon Kinesis is based on Apache Flink. One complaint might be the branding but keep in mind that the Apache Foundation has a strict policy of enforcing trademarks. The Apache Foundation itself doesn't choose winners and many equivalent projects live under the same umbrella, just like Flink and Kafka. Performance is often transient and it isn't the only criteria used when choosing a vendor. Some enterprise customers prefer a single vendor, i.e., "one throat to choke". Others have very specific constraints: greenfield decision making is a luxury. My impression is that Amazon responds to customer requests to solve specific problems and they make a decent effort to continuously improve the performance and other aspects of their services. At one point people said "no one gets fired for choosing IBM" and this switched to Microsoft and, rightly or wrongly, Amazon AWS now wears this crown.
    • GordonS 6y ago
      > My impression is that Amazon responds to customer requests to solve specific problems and they make a decent effort to continuously improve the performance and other aspects of their services. I get that, but I would have thought it would make more sense to approach TimescaleDB for a licensing deal. That way, right from day one they get a mature product with incredible features and performance. And they'd win developer mindshare by supporting OSS.
      • csharptwdec19 6y ago
• CodesInChaos 6y ago
  Does timescale have a page giving a clear overview of the different offerings/editions and their features and limitations?
  • akulkarni 6y ago
    Were you looking for something like this? https://www.timescale.com/products https://www.timescale.com/products
    • CodesInChaos 6y ago
      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-business-in-cloud-era-v2/ https://blog.timescale.com/blog/building-open-source-busines.... I would have expected one place which compares all available options.
      • akulkarni 6y ago
        Here you go: - Community features: All features labeled with "community" on here: https://docs.timescale.com/latest/api 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-business-in-cloud-era-v2/ https://blog.timescale.com/blog/building-open-source-busines... Hope this helps. Will pass along the feedback to the team :-)
        • CodesInChaos 6y ago
          The documentation still talks about buying an enterprise edition: https://docs.timescale.com/latest/getting-started/exploring-enterprise https://docs.timescale.com/latest/getting-started/exploring-...
• momothereal 6y ago
  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 because it causes partition issues.
  • mfreed 6y ago
    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 =)
    • momothereal 6y ago
      Wouldn't that just make the pair unique? That would still allow you to insert rows with the same row_id, but different time.
      • djk447 6y ago
        Why not create an index on user_id, time? Why do you need a unique reference back to the row? We find that they're often (though certainly not always) kind of meaningless and/or unnecessary for timeseries workloads.
        • momothereal 6y ago
          Yes that's what the reply suggested. However the business requirement is that the row_id should be unique, such that looking up a row by ID is guaranteed to have 0-1 results. A unique constraint on (row_id, time) doesn't satisfy that.
          • 6y ago
• ahachete 6y ago
  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 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).
  • ryanbooz 6y ago
    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?
    • ahachete 6y ago
      Note that DynamoDB's PartiQL support is not an architectural pattern but rather a "simple" translation layer on top of the current three read operations. It doesn't say much to me tbh. I wouldn't say is impossible to say. Maybe impossible with 100% certainty, obviously, but for me it's quite clear ;)
  • jeremycarter 6y ago
    I might take toro for a spin this weekend.
    • ahachete 6y ago
• nwsm 6y ago
  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 like a win for opensource, but not so much for serverless users. Slightly off topic: I have a side project that generates ~10 daily metrics for ~350 entities. Around 150k readings currently (the number of metrics gathered per entity per day has increased since I started). I'm pretty interested in these timeseries databases, but I think my use case is still on the side of using MySQL/Postgres out of the box. Not to mention that I can get by with archiving data > 1 year old. Does anyone have any quick checklist or metrics to make decisions like this? When does it make sense to evolve from a vanilla RDB to a timeseries one? [0] https://news.ycombinator.com/item?id=24579905 https://news.ycombinator.com/item?id=24579905
  • mfreed 6y ago
    Hi @nwsm: Timescale offers a fully managed version of TimescaleDB on AWS, GCP, and Azure, starting at $49/month. https://www.timescale.com/timescale-signup https://www.timescale.com/timescale-signup
    • nwsm 6y ago
      Thank you. At that price it's probably overkill for me, but I wish you had more info on your site that wasn't gated by a signup. How is the product managed in my GCP environment?
      • mfreed 6y ago
        Sorry harder to found, but pricing calculator on product page (not gated): https://www.timescale.com/products#pricing https://www.timescale.com/products#pricing
  • ryanbooz 6y ago
    I'd just add that if you have any belief that your application will grow, and it's time-series in nature, there's usually only upside to starting with a time-series specific database now. The hoops you'll jump through as the application grows will often bring you more headache than you can imagine now. Before coming to work at Timescale a few months ago, I spent 18 years managing products at two companies, both of which were time-based applications (utility billing/energy data & IIoT). In both cases, the app started small and everything seemed fine. We could usually get around performance issues with other hacks. But in both cases there was a tipping point because the original database (one relational, no NoSQL) just wasn't designed for the challenge as the app scaled. So whether you manage it yourself in a smaller environment for now or try something like Timescale Cloud, I can (almost) guarantee that you'll thank yourself in a year or two. ;-)
• rafaelturk 6y ago
  Little bit Offtopic: From a Dev perspective how TimescaleDB is better/worse than regular postgresql?
  • drpebcak 6y ago
    It is a postgresql extension that you install on top of a normal postgresql server, so it is not worse in any way. Timescale works by creating a 'hypertable', which is an aggregate of a lot of smaller 'chunk' tables. These chunk tables are automatically split by date or incrementing id. This means that for queries that specify IDs or a date range within a certain range, you only have to query results within a few chunks, instead of looking through all the contents of the entire 'hypertable.' [1] Timescale also offers some other things like compression which can save you up to ~96% disk space while also improving query performance in some cases. [2][3] It also has something they call 'continuous aggregates' [4], which are similar to postgresql's materialized views, but do not require manual refreshing - they instead update periodically through an automatic background job. There is also a feature which builds on this called 'realtime aggregates' that allows you to combine the data within a continuous aggregate with the raw data in the tables that has yet to be materialized. There are a lot more things besides that, but I think that's a decent overview of the major features it brings to the table. From a dev perspective these things all make the data and the database easier to work with (especially targeting timeseries data). There is an api reference [5] that has some of the other commands timescale adds, if you want to see some of the other things it can help you do. [1] https://docs.timescale.com/latest/using-timescaledb/hypertables https://docs.timescale.com/latest/using-timescaledb/hypertab... [2] https://docs.timescale.com/latest/using-timescaledb/compression https://docs.timescale.com/latest/using-timescaledb/compress... [3] https://blog.timescale.com/blog/building-columnar-compression-in-a-row-oriented-database/ https://blog.timescale.com/blog/building-columnar-compressio... [4] https://docs.timescale.com/latest/using-timescaledb/continuous-aggregates https://docs.timescale.com/latest/using-timescaledb/continuo... [5] https://docs.timescale.com/latest/api https://docs.timescale.com/latest/api
    • ryanbooz 6y ago
      Great summary, thanks! The two main things most developers will benefit from is how we manage the automatic partitioning of your incoming data (hypertables), something which is non-trivial to do yourself even though other tools exist for it. And because we do it with a time-based focus, we can be really efficient and smart about it. Second, we've improved the query planner in PostgreSQL around the parts that relate to querying time-based, partitioned data, and provided special time-based functions. These improvements help you efficiently query data that time-series applications most often need. A quick example is something like "LAST()", which retrieves the most recent value for a given time-range. There are ways in SQL to do something similar (LATERAL JOINs or CTEs for instance), but they're usually slower and bulkier to maintain. When dealing with time-series data, getting the most recent value for an object is usually what you're doing the most often. When you add those two foundational features, everything else that @drpebcak mentioned become amazing value-adds that you just can't get elsewhere.
• bfrog 6y ago
  Who can keep up with all these cloud services... there must be over a thousand now between azure, gc, and aws.
• sudhirj 6y ago
  This reads like a Postgres vs DynamoDB comparison, because that’s likely what it is. The article makes a lot of points really well, and if I had 8 highly qualified people who had nothing else to do on my team working for free (or on salaries that were a rounding error in my actual and opportunity cost budget), I’d certainly get them to learn and use Timescale. But I don’t right now, so I’m going to use the option that gives me a time series DB with three or four clicks, gets the job done, and charges me for deployment and maintenance amortised across thousands of other customers. Having these arguments purely on cost of service terms is a very slippery slope. Yes, it’s less dollars paid in hardware if I put my life on hold and learn how to configure this. Or pay someone else to do it. Yes, it’s cheaper if I order parts on newegg, build a server, drive to a colo and install it in the rack, and then drive there again each time something breaks. And yes, it’s even cheaper if I run it off a Raspberry Pi duct taped under my desk. No one is disputing these things. AWS and other cloud providers sell peace of mind, acquisition and procurement speed, professional maintenance and remediation, deep integration, faster development and testing, and infrastructure management - with servers thrown in for free. Timescale sells time series database software. This is not a valid comparison.
  • deleted 6y ago
    [deleted]
  • mfreed 6y ago
    1. Timescale sells a fully managed service offering running on AWS, GCP, or Azure. So you can get started with 3-4 clicks and have a database running in 30 seconds. (We actually don't sell "software" at all - that's all free to download and run yourself.) We're fully aligned that cloud services often have lower TCO in the long run =) https://www.timescale.com/timescale-signup https://www.timescale.com/timescale-signup 2. Beyond operations, your team probably already knows how to use much of TimescaleDB, if they know SQL and PostgreSQL. AWS Timestream, on the other hand, introduces a bunch more of strange gotcha's, as evidenced in the blog post (even from the weird SQL hoops that you need to jump through.)
    • sudhirj 6y ago
      The managed cloud feature is great, so if there's a comparison happening it'll be much more valid if you do a like-to-like one. I'd be more interested to see that the numbers (performance and cost would be) if you ran the comparison with Timescale Cloud managed, on AWS, with EBS set up (and note IOPS settings) at a comparable provisioned size with multi-AZ failover. Doing that and checking costs would be much fairer from a cost-per-metric point of view.
• chrissnell 6y ago
  I looked at Timestream at my previous job and my research left me thinking, "Who uses this thing?". Expensive but most annoying of all, the only Grafana plugin was in private paid beta. It looks like they've finally open-sourced it.
• fredliu 6y ago
  Elephants in the room: 1) comparison with Druid, and 2)Learning curve and Ops load comparison.
  • valyala 6y ago
    3) comparison with ClickHouse 4) comparison with VictoriaMetrics
• aantix 6y ago
  Doesn't look like Timescale supports Postgres 13. Hmmm.
  • ryanbooz 6y ago
    We've been hard at work with lots of great features for TimescaleDB 2.0, which should be GA in the next couple of weeks which makes multi-node available for anyone to use! There is a branch for PostgreSQL 13 support available for beta testing if you want to build it yourself. It's important to us and we'll focus on completing that integration soon! https://github.com/timescale/timescaledb/pull/2498 https://github.com/timescale/timescaledb/pull/2498
    • aantix 6y ago
      Thanks Ryan!
• awinder 6y ago
  When you jumped between these AWS instance types did you tune / monitor to see what resources were becoming constrained? Or can you provide some details on network / VPC setup and changes to http connection pools in the AWS SDK? Since timescaledb is communicating over HTTP through the AWS client, I'm wondering how much you can tune to eek out performance there. I've been burned so many times across AWS services on classes of error like this that I'm just casually curious, not that anything was done "wrong".
• rubiquity 6y ago
  Disclosure: I work at AWS but not on Timestream. Opinions my own. Unless I'm missing something this is not an apples to apples benchmark. TimescaleDB is running as a single node without any replication whereas Amazon Timestream is replicated[0] to three AWS Availability Zones for durability. I've only skimmed the TSBS[1] repo and the start/stop scripts for TimescaleDB. Can someone confirm this? 0 - https://aws.amazon.com/blogs/aws/store-and-access-time-series-data-at-any-scale-with-amazon-timestream-now-generally-available/ https://aws.amazon.com/blogs/aws/store-and-access-time-serie... 1 - https://github.com/timescale/tsbs https://github.com/timescale/tsbs
  • ryanbooz 6y ago
    Our experiments all ran on cloud instances (DO and Timescale Forge) that use storage that are replicated across multiple AZs/racks for greater reliability and fault tolerance.
    • rubiquity 6y ago
      Nice! Multiple AZs or Multiple racks? EDIT: Also your response contradicts what is in the blog post: > 1 remote client machine, 1 database server, both in the same cloud datacenter > Disk Size: 4.8TB of disk in a raid0 configuration (EXT4 filesystem)
      • mfreed 6y ago
        On our managed Timescale Forge, it's multiple AZ. (On some benchmarking equipment on Digital Ocean, it's advertised as "multiple racks", but managed to reduce blast radius.)
        • rubiquity 6y ago
          This contradicts what is in the blog post. From the machine configuration section: > 1 remote client machine, 1 database server, both in the same cloud datacenter > Disk Size: 4.8TB of disk in a raid0 configuration (EXT4 filesystem) Both those statements lead me to believe it's a single server with locally attached SSDs in a RAID0. Which is it? I know benchmarking is hard, and it's difficult to test certain aspects of Amazon Timestream due to it being a managed service, but I really think these details need to be firmed up to make sure you are comparing apples to apples. TimescaleDB seems like a cool product. Another suggestion I'd make is to run the Amazon Timestream clients across multiple AZs if you aren't already. The blog post doesn't mention whether all the t3 instances are in the same AZ or not.
• misterbwong 6y ago
  Serious question: Why doesn't AMZ just buy TimeScaleDB instead of building their own? Time series db's in general seem to fit their vibe pretty well: it's a new hot tech, it's usually deeply embedded into infrastructure, and requires loads of bandwidth & storage.
  • kdtsh 6y ago
    Timescale isn't exactly huge yet, but their potential is enormous - but so is the potential in building a competing product offered as a service. Unless Amazon want to put at least 8 zeros in their offer, I can't see it happening, and at that point Amazon might as well hedge their bets and build their own offering (which is exactly what they're doing). At worst, their offering will be only _okay_, and at the same time Timescale is doing business with Amazon by hosting DaaS instances on their infrastructure, which I'm sure Amazon takes a handsome cut from.
• netik 6y ago
  Timestream hasn't even really been generally released as best I can tell. We wanted to use it, went to TimescaleDB, and then ended up going to Druid to improve performance. Seriously, If you need to do this at scale, use Druid. It's much more efficient for time-series data.
• chmod775 6y ago
  Ah yes. The horizontal scalability endgame. Amazon designed a system that is perfectly horizontally scalable. The only issue is that they now need 33,000 machines to achieve the throughput of TimescaleDB running on a single node. I would call the results this new school of software development produces horrifying, but I already get lynched every time I tell a startup that their horrifyingly complex horizontally 'scalable' AWS setup that costs them $10k a month could be replaced by a handful of ducktape running on a rPI. The best part is how the scaling never really works and just adding a load balancer and a second rPI would've worked better. "We didn't think we'd get that many users. I mean 10k! Whew! It just wasn't designed for this!" "Oh. That sucks. My rPI is serving 2 million monthly visitors right now and I'm still waiting for CPU usage to dip into the double digits." I'm not saying people should design their stuff to handle millions of users on underpowered hardware, but I am suggesting they not lose their sense of perspective while building their whatever. Because if you do, you may end up thinking you did well when your DB maxes out at 500 inserts/second - Another DB running on a Nintendo DS might just outperform it.
  • valyala 6y ago
    Horizontally scalable systems are usually slower than single-node solutions because of overhead on passing data between nodes. We at VictoriaMetrics clearly see this - cluster version of VictoriaMetrics needs up to 2x more CPU and RAM resources comparing to a single-node version for achieving the same performance. Single-node VictoriaMetrics provides almost perfect vertical scalability though. Its' performance scales almost linearly from rPI to a monster with hundreds of CPU cores and terabytes of RAM. See https://valyala.medium.com/measuring-vertical-scalability-for-time-series-databases-in-google-cloud-92550d78d8ae https://valyala.medium.com/measuring-vertical-scalability-fo... and https://valyala.medium.com/billy-how-victoriametrics-deals-with-more-than-500-billion-rows-e82ff8f725da https://valyala.medium.com/billy-how-victoriametrics-deals-w... .
• pezezin 6y ago
  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 the development team!
  • ryanbooz 6y ago
    Thanks for sharing! Glad to hear it's been a successful venture for you. Hope we get to hear more about it at some point!
    • pezezin 6y ago
      Sure. I have been discussing your amazing product internally, but I hope I can promote it next time I go to an accelerator conference or workshop.
  • mfreed 6y ago
    Hey pezezin - would love to hear more if you are open to it. Can you ping me at mike @ timescale.com?
    • pezezin 6y ago
      Sure, I just sent you an email.
  • valyala 6y ago
    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/attachments/1972189/3281133/CMS_mon_RD_for_opInt.pdf https://indico.cern.ch/event/877333/contributions/3696707/at... and https://arxiv.org/pdf/2007.03630.pdf https://arxiv.org/pdf/2007.03630.pdf .
    • 6y ago
• ishikawa 6y ago
  AWS should pay a special Enterprise agreement to companies like MongoDB and Timescale so they could really host and resell the product. It would be good for users and license owners, and I guess for AWS also. GCP and Azure would soon follow.