Live data from Hacker News

TimescaleDB raises $40M

blog.timescale.com

31–40 of 143 posts

Re: TimescaleDB raises $40M

#31

> 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, with enough techno-jargon to maintain plausible deniability. Folks feel threatened by a great idea so it's safer to find some way to tear it down. Not to dismiss all feedback as projected insecurity of course.

Re: TimescaleDB raises $40M

#32
post #26

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!

That's awesome. Y'all are going to crush it, especially since I saw that lots of companies have an appetite for adopting new backends, especially dbs that can work in both on-prem & in cloud.

Re: TimescaleDB raises $40M

#33
post #26

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!

We too are also doing something similar. We've just started the move to timescale for real-time energy and sensor data from industrial assets. We have a single customer with about 10TB of data and growing from 2 years worth of real-time monitoring which is stored in a mixture of table storage and SQL. Timescale on PG seems like blessing for our future plans :)

Re: TimescaleDB raises $40M

#34

> 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

Just because it's a bad idea technically doesn't mean it can't be a business success. VHS beat Betamax.

Re: TimescaleDB raises $40M

#36

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…

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 something built on Postgres is going to be a better thought.

Again, this is just our problem space; small scale deployments on many machines with no preexisting RDMS, low cardinality data, etc. I think it’d be a different story if we were huge, but for us, InfluxDB provides some seriously handy feature and is worth consideration if your problem is similar.

Re: TimescaleDB raises $40M

#37

> 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

Technically you don't need a good idea to raise $40 million these days. /s

To me building upon PostgreSQL was however, a good idea. Long term all databases gain relational features, through a rather painful process of realization that RDBMS actually did some things right. They'll skip that pain and focus on new features.

Microsoft does something similar by offering a Graph DB on top of MS SQL.

Re: TimescaleDB raises $40M

#38

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.

What company is that?

I suspect AVEVA PI (formerly OSIsoft) is what they are referring to. PI is excessively popular in Enterprise scenarios either OT or IT.

Re: TimescaleDB raises $40M

#39

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.

What company is that?

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

Re: TimescaleDB raises $40M

#40

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…

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…

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.

This is likely in part due to the fact that I'm using well-understood internal data from real production systems, and as such my ability to be able to build performant indexes / query strategies in the database that I know best introduces a performance bias.

I always take benchmarks with a grain of salt, for this reason. And I try to lean into the tech I understand best.

Post reply on HN