Live data from Hacker News

TimescaleDB raises $40M

blog.timescale.com

71–80 of 143 posts

Re: TimescaleDB raises $40M

#71

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…

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 evaluate two _different_ ways to use time-series data with MongoDB (culled & optimized from suggestions in MongoDB forums). But always welcome to feedback:

https://blog.timescale.com/blog/how-to-store-time-series-dat...

Thanks!

Re: TimescaleDB raises $40M

#72
post #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, wit…

There’s also a tendency to think: “I don’t need this, so neither does anyone else”. I know that guilty of applying that logic more times that I’d like.

Re: TimescaleDB raises $40M

#73

Earlier quoted context omitted.

TimescaleDB isn't an alternative to KDB+. KDB+ is more a programming platform than a database.

I just do not want to be forced to use kdb/k/q ever again

An alternative is to build a system on a top of data warehousing technology, but it's very tough, so many stuff built on top of KDB+, I think it will stay for there for next two decades.

Re: TimescaleDB raises $40M

#74

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

Re: TimescaleDB raises $40M

#75
post #71

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

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 :-)

Re: TimescaleDB raises $40M

#76

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…

You will find a lot of people (myself included) who've bet on InfluxDB and sorely regretted it afterwards. It's not even remotely close to Postgres and Timescale in reliability, and to be honest hardly production ready if you work with critical data.

Re: TimescaleDB raises $40M

#77
post #56

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.

Or overwrite those data points.

Re: TimescaleDB raises $40M

#78

Earlier quoted context omitted.

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.

Oops :) You're right, fat fingered some quick calc

Re: TimescaleDB raises $40M

#79
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! :)

Hi John, good to hear from you! (And thank you :-)

Re: TimescaleDB raises $40M

#80

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 "don't host a cloud database and charge for it" to stop Amazon from building TimescaleDB right into RDS, or similar.

I think it's a totally fair license without too much to worry about if they go out of business.

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

This would be my biggest worry. Upgrading Postgres is already stressful enough, having to deal with broken APIs from version to version would leave me pretty upset, though I've not heard of anyone complain about this before, so I'm not sure how much of a problem this is in practice.

Post reply on HN