101–110 of 203 posts
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 tha…
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/
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?
Earlier quoted context omitted.
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
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?
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 m…
It's not just this. In many cases, the services launched are essentially MVPs that were only created to serve a handful of customers' needs. If a huge whale of a customer says they want hosted Jupyter notebooks on AWS (just a theoretical example I picked because I saw someone criticize Sagemaker, but I don't have any specific knowledge of Sagemaker), then AWS will create that for them, but, AWS doesn't actually do "one off" services for a specific customer, so they will also launch those hosted notebooks as a public service.
The result is of course that this service was built with one customer's use case in mind, so it might not serve other customers' use cases very well, which leads to some negative perception. But ideally AWS then goes and incorporates feedback into the service, turning it into a "tier 1" service rather than an MVP. It just takes time.
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?
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…
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. ;-)
Little bit Offtopic: From a Dev perspective how TimescaleDB is better/worse than regular postgresql?
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 chu…
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.
Little bit Offtopic: From a Dev perspective how TimescaleDB is better/worse than regular postgresql?
The documentation on their website [2] is also very good.
[1] https://github.com/vincev/tsdbperf [2] https://docs.timescale.com/latest/main
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…
In a recent webinar for capital markets, AWS didn't even try to advertise Timestream, they talked about the three most popular tsdb in finance and that's it. Source: https://pages.awscloud.com/awsmp-h2-fin-time-series-database...