TimescaleDB raises $40M • Hacker News Board

Re: TimescaleDB raises $40M

#51

Post by Croftengea » Wed, May 05, 2021, 4:01 PM UTC

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 one can get some ideas about their development directions from their issue tracker and source code, but they don't have any public product roadmap.

* Even though the product itself is technically very stable, the version compatibility leaves a lot to be desired. There are removed features and broken APIs from version to version.

* Their commercial support terms for on-premise instances don't seem to be well defined, not publicly at least.

Re: TimescaleDB raises $40M

#52

Post by andrenotgiant » Wed, May 05, 2021, 4:03 PM UTC

kirse wrote: post #31

simplify wrote: post #13

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

I've been working on a rubric for evaluating HN reaction to "Show HN" launch posts:

1. Universally Negative - Either it's cryptocurrency-related, or it depends on source of negativity:

   A. "I read the site and I don't know what this is" - Genuinely bad explanation of an idea that doesn't seem particularly technically interesting or challenging.

   B.  Criticism of superficial aspects (e.g. website, related topics) - Genuinely bad explanation of an idea that DOES seem particularly technically interesting or challenging. _(Commenters don't get the message, but are worried they'll appear ignorant if they say it.)_
   
   C. "Nobody needs this" "Why is this a thing" - Either bad or HN is nowhere near the target audience.

   D. "This is not the right way to do it" "You can just do X" - Either bad or revolutionary (and new enough that the idea hasn't clicked with anyone.)

2. Polarization -

    A. If positive people are REALLY positive about it - potentially a disruptive technology, potentially ahead of its time.

    B. If negative people say it's actually much harder to solve - the idea is great in principle but the only reason it hasn't already been solved is it's not possible or very difficult in practice.

3. Universal Adulation - It will transparently never make any money, it is some kind of attempt at decentralization that will never get adoption beyond hardcore nerds.

Re: TimescaleDB raises $40M

#53

Post by rhodozelia » Wed, May 05, 2021, 4:03 PM UTC

mfreed wrote: post #26

ironman1478 wrote: post #18

This is awesome. In certain industries (manufacturing, energy, etc) there are companies (really 1 company) that essentially have monopolies on time series databases / historians. There has been 0 competition in that space and as a result the databases and surrounding client tools are just so awful. It'll be interesting to see if timescaledb can really enter that market and force those companies to adapt.

We actually see a bunch of startups directly going after that market leader in historian space that are building on _top_ of TimescaleDB. So they can bring their domain expertise in process manufacturing and elsewhere, and then build on a modern, powerful platform. We're excited to see this!

I would love to known of some alternatives to Rockwell, wonder ware, Schneider to propose to our customers. What startups are building on top of timescale?

Re: TimescaleDB raises $40M

#54

Post by ironman1478 » Wed, May 05, 2021, 4:04 PM UTC

etaioinshrdlu wrote: post #41

kirse wrote: post #31

Earlier quoted context omitted.

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…

I'm still confused why time-series databases are even a thing. It seems to me that time-series just means you have a date/time column plus an index on it. Which is something typical databases already do well, and like the referenced post mentioned, you could use a column store for better performance. But I just don't see anything that makes creating an entire database design for one specific index type worthwhile...…

Certain time series databases tend to me be optimized towards making the most recent data readily available and quick to fetch. There are also certain filtering / compression algorithms that are run on these time series databases that only make sense in a time domain.

Also, some of these time series databases have very specific use cases and you have to also think about the client tools associated with the database. Many of these databases sit in power plants, factories, etc. and they stream data to tools that are built to visualize or analyze the last few minutes of data and then trigger alerts based on patterns. Also, these database are very "device" aware and integrates with other systems that represent their data in a timeseries fashion already (like a sensor). A lot of customers who needed this type of database care only about this index because their concern is record keeping and monitoring. Not necessarily number crunching (this is changing though).

There are drawbacks to storing your data this way. If your primary index is time, it can be hard to merge that with some based on a coordinate system. So doing certain types of analysis is really difficult unless you replicate your data into some other database with a different index.

Re: TimescaleDB raises $40M

#55

Post by Croftengea » Wed, May 05, 2021, 4:05 PM UTC

throwaway375 wrote: post #50

I think idea and promise of Timescale is great, but current(well actually I tried it 1 year ago) state of things makes it very hard to choose Timescale over Clickhouse. I've tried to setup simple Twitter parser for trends analysis, so I needed few thousand counters every few seconds. While I did not encounter any perfomance issues, size on disk was a huge deal. I don't remember precise numbers, but Clickhouse used fe…

Did you turn on compression in TSDB?

Re: TimescaleDB raises $40M

#56

Post by gsich » Wed, May 05, 2021, 4:06 PM UTC

some0x80070005 wrote: post #22

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

Influxdb makes it really hard to delete data.

Example: your temperature sensor is faulty and produces values like -100. You can't delete this data by using "delete from measurement where temperature < -50". You have to get all timestamps, then delete those timestamps one by one.

Re: TimescaleDB raises $40M

#57

Post by _joel » Wed, May 05, 2021, 4:07 PM UTC

msaharia wrote: post #35

_joel wrote: post #20

We used TimescaleDB for a flood prediction tool, works really well, kudos.

Hi, I am a hydrologist. Would love to hear about what you have done using TimeScaleDB

We used historical flow meter readings (started out with 15 minute intervals but it worked much better with a higher frequency) and used that to train Recurrent Neural Networks (RNN's) to predict where areas were likely to flood. I was the devops lead on it for the prototype, not the data scientist unfortunately so can't give you the in's and outs but can tell you that we used tensorflow together with pandas/df/timescaledb. We then displayed that using plotly, all this was stuffed inside several containers. It was a great project to work on actually. The whole setup was pretty much a joy to work with.

Re: TimescaleDB raises $40M

#58

Post by alexmarcy » Wed, May 05, 2021, 4:07 PM UTC

kevinherron wrote: post #39

ltnublet wrote: post #24

Earlier quoted context omitted.

What company is that?

He's probably referring to OSIsoft's PI historian.

Their stuff is a nightmare to use, and is insanely expensive.

Always nice when we get to just swap it out for something like Canary or even Ignition although folks are always trying to trash the Ignition Historian when it works well for most use cases people need to solve.

Re: TimescaleDB raises $40M

#59

Post by gsich » Wed, May 05, 2021, 4:08 PM UTC

What 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.

Re: TimescaleDB raises $40M

#60

Post by gautamcgoel » Wed, May 05, 2021, 4:09 PM UTC

cookguyruffles wrote: post #45

etaioinshrdlu wrote: post #41

Earlier quoted context omitted.

I'm still confused why time-series databases are even a thing. It seems to me that time-series just means you have a date/time column plus an index on it. Which is something typical databases already do well, and like the referenced post mentioned, you could use a column store for better performance. But I just don't see anything that makes creating an entire database design for one specific index type worthwhile...…

The internals are completely different. Given the collection of software technologies we posses today, you can't assemble them around a database using a row-oriented encoding and come up with something that can outperform (in space, time and cost) the kinds of query styles that column-oriented encodings absolutely murder. Logically they're the same thing, but engineering is about details, details in this case that co…

That's way more than 87M samples, more like 300B.