Live data from Hacker News

TimescaleDB raises $40M

blog.timescale.com

21–30 of 143 posts

Re: TimescaleDB raises $40M

#21
TimescaleDB looks great. I'm interested in using it but I'm concerned about the upgrade path across major PostgreSQL versions. Logical replication is a big help when upgrading PostgreSQL across major versions while minimizing downtime. As far as I understand it, TimescaleDB doesn't support logical replication yet. Major version upgrades with TimescaleDB is obviously a solvable problem but it probably means we'll have a more complicated upgrade path. Upgrading via logical replication is just so nice.

Re: TimescaleDB raises $40M

#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 TimescaleDB vs InfluxDB. We use these more complex queries and have no problem on Influx. Going further, the number of functions built in is impressive with the same ability to define new functions.

* InfluxDB containers are totally self contained which is great for simple architectures. As a process, InfluxDB is a single executable thanks to Go.

* This is extremely subjective, but I find Flux easier to comprehend as a separate query vs. the use of SQL to do higher complexity functions; however, I am sure this is due to my lack of experience and know how to write said queries in SQL.

Re: TimescaleDB raises $40M

#23
post #16

I was in Grand Central Tech with the Timescale folks, became friends with both Ajay and Mike. Ajay gave me a lot of good thoughts on building my startup(thanks!), and Mike is..well.. just hyper smart. That is to say, I'm not surprised to read this and for what it's worth: they deserve it, really great humans! :)

Thanks, super appreciated! I remember always enjoying our conversations as well!

Re: TimescaleDB raises $40M

#24

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?

Re: TimescaleDB raises $40M

#25
post #7

Earlier quoted context omitted.

Why? I'm genuinely curious, since I've never worked with kdb but I've often heard great things about it (regardless of the weird query language).

Kdb is like oracle db that somehow won’t die. It could use some competition

Standard SQL is rubbish for time series queries as it is based on set theory which does not have order. Most SQL datbases exploit that fact to increase performance. Fundamentally kdb is based on ordered lists, which is a much better paradigm for time series data.

The contrasting queries can be seen here: http://www.timestored.com/b/kdb-qsql-query-vs-sql/

I do agree they could use competition as the overall offering is weak but the core database is very strong.

Re: TimescaleDB raises $40M

#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!

Re: TimescaleDB raises $40M

#27

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 TimescaleDB, I don't have to learn a new tool and query language. Development is complex enough and I have to learn too many things as it is. The older I get the less enthusiastic I am about adding something new to the stack.

Re: TimescaleDB raises $40M

#28

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?

KDB in finance?

Re: TimescaleDB raises $40M

#29

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 was employed there so I don't feel entirely comfortable stating their name. Just google around for "operational historian". It was really frustrating because we had these ideas years ago (and many other ideas), but due to reasons we were not allowed to actually make the product genuinely better. Also, the product is in more places than you'd think because they partner with vendors to sell the database as a component in a larger system that the vendor packages up and sells.
Post reply on HN