TimescaleDB raises $40M • Hacker News Board

Re: TimescaleDB raises $40M

#91

Post by mfreed » Wed, May 05, 2021, 5:06 PM UTC

Croftengea wrote: post #86

akulkarni wrote: post #70

Earlier quoted context omitted.

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.

Fair point about adaptive chunking. You sound like a long-term user!

There is always a trade-off between getting features to users quickly to experiment and incrementally improve, versus doing it always very conservatively.

When we launched adaptive chunking (introduced in 0.11, deprecated in 1.2), we explicitly marked it as beta and default off, to hopefully reflect that. [1]

The approach we are now taking with Timescale Analytics [2] is to have an explicit distinction between experimental features (which will be part of a distinct "experimental" schema in the database, and must be expressly turned on with appropriate warnings) and stable features. Hopefully this can help find a good balance between stability and velocity, but feedback welcome!

[1] https://github.com/timescale/timescaledb/releases/tag/0.11.0

[2] https://github.com/timescale/timescale-analytics/tree/main/e...

Re: TimescaleDB raises $40M

#92

Post by sylvain_kerkour » Wed, May 05, 2021, 5:07 PM UTC

cevian wrote: post #74

sylvain_kerkour wrote: post #63

Congrats! I really love the approach they took to deliver value: An extension of an existing rock-solid platform (Postgres) instead of building a new server which would require a lot of time to learn and manage. Is TimescaleDB suitable to store logs? If yes, how to architect the tables?

(Timescale engineer here). We believe so and we have customers using us for just that. We haven't created our own product for that yet (as we have for metrics -- Promscale) but it is an idea we are playing with. You may want to look at our Promscale design doc[1] for ideas on table layout. [1] https://tsdb.co/prom-design-doc

Great to hear, thank you!

Re: TimescaleDB raises $40M

#93

Post by DetroitThrow » Wed, May 05, 2021, 5:23 PM UTC

Croftengea wrote: post #51

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

Even though it is proprietary, I appreciate the current fine print in their current Timescale license compared to most other proprietary licenses. It doesn't have scary ambiguous language that could apply to even small, non-cloud-provider users that the SSPL contains, and they have nice "we won't sue you" clauses that were written favorably for users.

At least that's what I think, I'd want to hear kemitchell's review of the most recent iteration of their license, I think it incorporates much of what he's discussed as the correct legal direction for open-except-for-clouds licenses which strikes the right balance between user protections and safe guards against cloud providers.

Re: TimescaleDB raises $40M

#94

Post by mfreed » Wed, May 05, 2021, 5:33 PM UTC

justin_oaks wrote: post #90

slashdev wrote: post #27

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

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/in…

One of our active community members took over the effort to merge PostgreSQL/TimescaleDB support into telegraf here, so hopefully that can make progress:

https://github.com/influxdata/telegraf/pull/8651

Re: TimescaleDB raises $40M

#95

Post by cperciva » Wed, May 05, 2021, 5:38 PM UTC

Croftengea wrote: post #51

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

they betted

Just in case you're not a native English speaker: The verb "to bet" is irregular and the past tense is simply "they bet" rather than "betted" (which would be far more logical).

Re: TimescaleDB raises $40M

#96

Post by js4ever » Wed, May 05, 2021, 5:43 PM UTC

I'm using TimescaleDB more and more, I just deployed another instance this morning for another customer that need to store timeseries (hundreds of servers metrics and some logs), I do have other instances in production since a year without any issues and the compression and expiration policy are really great for this use case! Thanks to the team.

Re: TimescaleDB raises $40M

#97

Post by justin_oaks » Wed, May 05, 2021, 5:47 PM UTC

mfreed wrote: post #94

justin_oaks wrote: post #90

Earlier quoted context omitted.

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/in…

One of our active community members took over the effort to merge PostgreSQL/TimescaleDB support into telegraf here, so hopefully that can make progress: https://github.com/influxdata/telegraf/pull/8651

Yeah, I saw that. I guess I'm a just a little disappointed that nobody at the TimescaleDB team saw through the process. But I understand if you have higher priorities.

I still wonder what other people are using to feed information into TimescaleDB. I'm wondering if I should switch to a different approach, such as using Telegraf but routing the data to something else that will push data into TimescaleDB.

Re: TimescaleDB raises $40M

#98

Post by thunkshift1 » Wed, May 05, 2021, 5:54 PM UTC

What are some of the use -cases to consider using any time series db? I cant think of much beyond stock charts and server logs

Re: TimescaleDB raises $40M

#99

Post by dataviz1000 » Wed, May 05, 2021, 5:55 PM UTC

akulkarni wrote: post #70

Croftengea wrote: post #51

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

Lately, I've been studying machine learning, from point zero, with a focus on time series analysis. Two months in already completed a course on Python and another book on Pandas, several hundreds of hours later in the fourth chapter in a book I paid for on deep learning and time series analysis they provided me with the most important information I needed: there is no evidence deep learning works better than traditional statistical analysis using classical methods like SARIMA and ETS. Sure, great, if an academic is interested in theory hopefully making a breakthrough, however, the rest of us who are interested in applied should stick with the classical methods.

I was going to write a lot here but I'll keep it short.

What I discovered is that everything I want to do can best be done in PostgreSQL. It's one thing to do data analysis in a Python notebook and another in an environment that works dynamically on a server. My first guess was to do the heavy lifting in Python with Numpy, Pandas, and machine learning and have the node server -- instead of Django and if I'm learning a new web framework it will be Phoenix -- execute the Python scripts through stdin / stdout. Since started I learned that I don't need machine learning and that I can do the calculations inside PostgreSQL sometimes orders of magnitude faster than in Python.

I'm using TimescaleDB which provides the postgresSQL time_bucket() function and with chunks should scale very well. First I tried to integrate it with Prisma in node, however, that proved to be far too difficult and convoluted. I reverted back to using TypeORM in node and it was extremely easy to run all the boilerplate code to initialize the TimescaleDB plugin inside of migrations which would probably be just as easy in another framework like Phoenix with Ecto. Sometimes I use SQL queries in a string literal and other times I use the query builder for more dynamic interaction with the database and to leverage some of TypeORM's other features beyond only being a connection manager.

What I discovered which interestingly someone yesterday shared a popular link to a blog post on the subject[0], for most of time series analysis, Pandas isn't required and perhaps not the fastest solution. Grokking window function was a little difficult until I found this lecture on YouTube, Postgres Window Magic[1]. Leveraging and understand window function in SQL is probably the most important skill to have.

I don't need Python and Pandas for time series analysis. I can using TimescaleDB and some increased knowledge of using PostgreSQL do time series analysis using all the same infrastructure I've been using for the past several years.

[0] https://hakibenita.com/sql-for-data-analysis

[1] https://www.youtube.com/watch?v=D8Q4n6YXdpk

Re: TimescaleDB raises $40M

#100

Post by lurkerasdfh8 » Wed, May 05, 2021, 5:56 PM UTC

3pt14159 wrote: post #80

Croftengea wrote: post #51

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

For background, I haven't used TimescaleDB before, but I've done some pretty advanced ORM work to vertically shard PG tables in Rails and I know PG pretty well, so I'm quite curious about TimescaleDB. > * Even though most of their code licensed under Apache license, some code is under their proprietary license. I don't really think this is a perfectly fair characterization. Their proprietary license is essentially "d…

> > * Even though most of their code licensed under Apache license, some code is under their proprietary license.

> I don't really think this is a perfectly fair characterization. Their proprietary license is essentially "don't host a cloud database and charge for it" to stop Amazon from building TimescaleDB right into RDS, or similar.

"yeah, go ahead, infringe that copyright and host a internal/for-direct-clients only database, because i guess that would be OK from their license, even though it is not explicitly allowed"

pardon the sarcasm, but i literally heard that from our lawyers today regarding another project's license, as something (quoting again) "no lawyer would ever say to their clients".