I've really enjoyed working with tsdb, we are using it in conjunction with hasura and it has been amazing how productive we feel.
Best of luck from a happy customer.
TimescaleDB raises $40M
81–90 of 143 posts
Re: TimescaleDB raises $40M
#82What I want in TimescaleDB is aggregation of old values in the SAME table. There is no use when I have to do this in a seperate table, Grafana overhead will be insane.
Have you looked at Real-time aggregates in TimescaleDB? It might help address the problem you are facing:
"With real-time aggregation, when you query a continuous aggregate view, rather than just getting the pre-computed aggregate from the materialized table, the query will transparently combine this pre-computed aggregate with raw data from the hypertable that’s yet to be materialized. And, by combining raw and materialized data in this way, you get accurate and up-to-date results, while still enjoying the speedups that come from pre-computing a large portion of the result."
https://blog.timescale.com/blog/achieving-the-best-of-both-w...
(You would then just need to query / point to the Continuous Aggregate to get the new and aggregated data in the same query)
Re: TimescaleDB raises $40M
#83Earlier quoted context omitted.
I wouldn't choose InfluxDB over TimescaleDB. There's a reasonably balanced comparison here from the Timescale guys: https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-... The benchmarks are interesting, showing TimescaleDB to be the clear winner in most scenarios. For me that's nice, but it's a bigger deal to me personally that I already have Postgres and SQL experience that translates directly to TimescaleD…
Fully agreed on having that SQL experience guiding you on a totally reasonable solution. However; our problem space is not high cardinality data; it more closely aligns to the first performance comparison with 10 devices and 10 metrics. The ease of getting high performance with pre implemented functions is great for us. Reliability is obviously a concern, and I can agree that if data is sacred, then choosing somethin…
We totally hear you that usability and the developer experience is super important, especially when starting out.
One project we launched earlier this year "Timescale Analytics" actually seeks to address exactly this, e.g., bring more useful features and easier programmability to SQL [1] and you can see (or add) to the discussion on github [2].
Also informed by some of the super helpful functions we've seen in PromQL. And by the way, if you are interested in PromQL, we have 100% compatibility with PromQL through Promscale [3], which provides an observability platform for Prometheus data (built on TimescaleDB).
[1] https://blog.timescale.com/blog/time-series-analytics-for-po... [2] https://github.com/timescale/timescale-analytics/discussions [3] https://www.timescale.com/promscale
Re: TimescaleDB raises $40M
#84> When we launched TimescaleDB, we met a fair amount of skepticism.... The top voted Hacker News comment at the time called us, “a rather bad idea[0].” Good old HN with its healthy skepticism :) [0] https://news.ycombinator.com/item?id=14036554
Having been on HN long enough, what I look for during any idea/startup launch is polarization and intensity of viewpoints. If people are reacting to the idea (for better or worse), it means its had an impact. Those are often the products that find success. A no-comment launch is far worse than one riddled with criticism. IMO HN's classic "skepticism" is usually just engineering nerd insecurity projected outwards, wit…
Similar to DropBox.
Re: TimescaleDB raises $40M
#85Earlier quoted context omitted.
Agree totally on the "double down on what you know" point. That pays off in spades usually. Tangentially related to that: their mongo benchmark numbers always looked odd to me. Given that I've used mongo for 10+ years for high throughput time series data without major issues, I decided to do my own benchmarks. In my testing, mongo outperformed timescale significantly both in write throughput and query performance. Th…
Hi @spmurrayzzz thanks for the feedback. (Timescale person) Always strive to do the best and fairest benchmarks we can, and for that reason, all our benchmarks are fully open-source for both repeatability and improvements/contributions: https://github.com/timescale/tsbs/blob/master/docs/mongo.md We also really did spend a lot of time investigating approaches with MongoDB, so you'll see our benchmarks actually evaluat…
Thanks for engaging here, and congrats on the round!
I've reviewed all these resources multiple times in the past, which is what prompted me to do my own benchmarks (in which mongo outperforms both multinode and single node configurations).
Some issues I noticed:
- youre using gopkg.in/mgo.v2 which is a mongo driver that hasn't had a release in 6 years. Not sure of the general performance impact here, but my tests use mongo 4.2 with a modern node.js driver. So thats one difference.
- your indexing strategy for mongo is easily changed to be able to get much better performance than the naive compound approach you took in the code (measurement > tags.hostname > timestamp).
- you didnt test the horizontal scaling path at all, this is where mongo arguably shines
I'm glad you all open source this stuff because it helps engineering leaders make better decisions, so thank you for that. But your data does not align with my own: either our production metrics or through structured load testing.
Re: TimescaleDB raises $40M
#86TimescaleDB is a great product, but if you plan to go with them long term, there are few points to consider: * They are still trying to figure out their monetization strategy. Initially, they betted on their on-premise Enterprise version, then abandoned it. Now they are pushing their cloud version. * Even though most of their code licensed under Apache license, some code is under their proprietary license. * I'm sure…
Timescale Co-founder here. Happy to address your concerns! 1. Monetization strategy This funding round is actually a sign that our business model is working really well. To quote Redpoint Ventures, who led this funding round: "The [Timescale] team capitalized on their significant community momentum last year, with their cloud business being one of the fastest-growing database businesses we have seen in the past 20+ y…
Thanks a lot for the straightforward response!
As for 4 - yes, I meant 2.0 and also removal of adaptive chunking in the earlier versions.
Re: TimescaleDB raises $40M
#87Earlier quoted context omitted.
Hi @spmurrayzzz thanks for the feedback. (Timescale person) Always strive to do the best and fairest benchmarks we can, and for that reason, all our benchmarks are fully open-source for both repeatability and improvements/contributions: https://github.com/timescale/tsbs/blob/master/docs/mongo.md We also really did spend a lot of time investigating approaches with MongoDB, so you'll see our benchmarks actually evaluat…
I also recall that when we [Timescale] first did our benchmarks vs Mongo for time-series, our use of MongoDB for time-series beat Mongo's own benchmarks :-) That's probably not something most companies would do for benchmarking, but we take ours seriously :-)
I appreciate all the work it takes to do them and document them. Doesn't go unnoticed I promise you.
Re: TimescaleDB raises $40M
#88TimescaleDB is a great product, but if you plan to go with them long term, there are few points to consider: * They are still trying to figure out their monetization strategy. Initially, they betted on their on-premise Enterprise version, then abandoned it. Now they are pushing their cloud version. * Even though most of their code licensed under Apache license, some code is under their proprietary license. * I'm sure…
Timescale Co-founder here. Happy to address your concerns! 1. Monetization strategy This funding round is actually a sign that our business model is working really well. To quote Redpoint Ventures, who led this funding round: "The [Timescale] team capitalized on their significant community momentum last year, with their cloud business being one of the fastest-growing database businesses we have seen in the past 20+ y…
To follow up Ajay's point, we really do take compatibility and stability seriously.
I believe that our "major version" upgrade from 1.x to 2.0 was the first time we changed/broke any APIs, but that involved a long beta/RC process, much documented about the changes [1], and upgrades that also meant to seamlessly migrate.
For example, upgrading from 1.x to 2.0 was still just running `ALTER EXTENSION timescaledb UPGRADE`. The main difference was if you were, for example, using some of our informational views in your applications, those had a change a bit. Or if you were querying internal catalogs in your app (although that is never recommended =)
Even after 2.0 was launched, we did backport bug fixes to some follow-on 1.x releases, and continued to support users running 1.x on our cloud platform.
[1] https://docs.timescale.com/timescaledb/latest/overview/relea...
Re: TimescaleDB raises $40M
#89TimescaleDB is a great product, but if you plan to go with them long term, there are few points to consider: * They are still trying to figure out their monetization strategy. Initially, they betted on their on-premise Enterprise version, then abandoned it. Now they are pushing their cloud version. * Even though most of their code licensed under Apache license, some code is under their proprietary license. * I'm sure…
Timescale Co-founder here. Happy to address your concerns! 1. Monetization strategy This funding round is actually a sign that our business model is working really well. To quote Redpoint Ventures, who led this funding round: "The [Timescale] team capitalized on their significant community momentum last year, with their cloud business being one of the fastest-growing database businesses we have seen in the past 20+ y…
> Most companies (including open-source companies) actually have both open-source and proprietary software, but the proprietary software is often hidden inside private repos. The difference with Timescale is that we have made the source code for our proprietary software available (on Github), even allowing users to modify it (eg "right to repair), and made all of our software free (ie no paid software features).
So I personally like your company, but I find these sorts of marketing speak responses obnoxious. Your communications strategy here is causing brand harm, not benefit.
1) You have an open source core, with proprietary components.
2) Open source adopters get a crippled product.
3) You have a custom license for the proprietary components, which is designed to allow people to make some use of those, but is poorly-written ambiguous (preventing many types of commercial use), non-open-source compatible (preventing integration into open source projects), and requires a lawyer to review (preventing integration by smaller projects).
This feels like your Achilles' Heel.
Troll Tech tried to go down this line for years, with their QPL license. And they even had sane messaging, where whenever I read your messaging, it feels weaselly, and it changes week-to-week. Still, they didn't really take off until they went with a licensing system customers could trust and understand.
The standard dual-license model would be AGPL and commercial (or GPL+commercial).
* Most open source developers won't mind (or even notice) licenses, so long as their open source and have the nice OSI and FSF logos.
* Most commercial companies won't mind paying $$$.
Commercial customers treat you like Microsoft. Open source developers treat you like community members. Hybrid customers are okay too; if I'm working on a piece of BSD code, I can use the AGPL license on your code, while commercial users of my code can buy a commercial license from you.
And if you insist on the crazy custom license, figure out the messaging. This was better than what I read before. "Proprietary with a public repo" makes more sense than previous messaging which sounded like open source but wasn't. At that point, at least the license overdelivers rather than underdelivers. I still trust that at some point, as an adopter who can't or won't use those components, they'll become increasingly mandatory if you ever fall on hard times. The problem is still that it makes it sound like you have open source and proprietary products. You don't. You have a product with open source and proprietary components, a confused freemium model, and not something I'd ever use without consulting a good lawyer, who in turn would tell me to stay away.
There are many other good models. You could go in the other direction and close up a bit too.
Re: TimescaleDB raises $40M
#90I guess this is an unpopular opinion, but I’ve found InfluxDB to be superb for being trivial to get going in a high performance way. I have never touched InfluxDB Cloud - always just InfluxDB either as an arbitrary process or container. Examples of where I’ve found InfluxDB to be more pleasant: * InfluxDB has way better documentation on functions. For example, look up moving average by time (not points) on TimescaleD…
I wouldn't choose InfluxDB over TimescaleDB. There's a reasonably balanced comparison here from the Timescale guys: https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-... The benchmarks are interesting, showing TimescaleDB to be the clear winner in most scenarios. For me that's nice, but it's a bigger deal to me personally that I already have Postgres and SQL experience that translates directly to TimescaleD…
I'm currently using InfluxDB (v1 not v2) and I've looked into switching over to Timescale DB.
Currently I'm stuck on figuring out how to get data into TimescaleDB. My company makes heavy use of Telegraf, which is a natural fit for InfluxDB, but not so much for TimescaleDB. The original pull request for the Telegraf plugin for Postgres/TimescaleDB was closed because the author was non-responsive: https://github.com/influxdata/telegraf/pull/3428
I can even write data to it using simple TCP or UDP tools like netcat or curl. And for some cases I have simple scripts that do exactly that. TimescaleDB, on the other hand, requires some sort of Postgres client.
What do you, or other people, use for writing data into TimescaleDB?