Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TimescaleDB raises $40M

blog.timescale.com

Post reply on HN
Print view View original

41–50 of 143 posts

Re: TimescaleDB raises $40M

#41

Post by etaioinshrdlu »

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

I index many tables on my site by num_upvotes so I can find the top ranked items to show. Does this mean that I need an UpvoteDB? I don't think so.

A previous time I argued this point, it was mentioned that you rarely need to update or delete old rows. This allows you to tailor the storage solution better. However, this basically means a compressed column store, which again, doesn't really have much to do with time.

Re: TimescaleDB raises $40M

#42

Post by dlevine »

ForHackernews wrote: post #34
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

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

Betamax was slightly technically superior, but the reason it lost was that Sony initially limited recording times to 1 hour. This meant that most movies required 2 Betamax tapes, vs 1 for VHS. Betamax players were also much more expensive.

The point is that a lot of "bad ideas" have something major going for them.

Re: TimescaleDB raises $40M

#43

Post by hetspookjee »

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

If I recall correctly TimescaleDB is mostly some extension functions for Postgres, with indeed some specific indices that vastly increase some often used insert & lookup query's. You can also just extend it with PostGIS for those really fancy smancy geographical oriented time series query's. Pretty neat stuff running out of the box. Here's the docker implementation: https://hub.docker.com/r/timescale/timescaledb-postgis/

Re: TimescaleDB raises $40M

#44

Post by Xcelerate »

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

I’m starting to think the best way to succeed as a startup is to get a bunch of negative comments when you announce your work on HN.

Re: TimescaleDB raises $40M

#45

Post by cookguyruffles »

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

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 could easily be a 2x to 20x budget difference given an appropriate project

A column store can take 100 years worth of samples occurring every 10ms that yield a constant result and using technology we actually have, represent those ~87 million data points on disk and in CPU using somewhere under 10 bytes.

Re: TimescaleDB raises $40M

#46

Post by whimsicalism »

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…

> IMO HN's classic "skepticism" is usually just engineering nerd insecurity projected outwards

HN is addicted to bikeshedding. It's among the top 3 comments on almost every "Show HN" or new product launch.

Re: TimescaleDB raises $40M

#47

Post by whimsicalism »

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…

But there are plenty of non-"time series DB" that are column oriented, maria, monet, etc.

Re: TimescaleDB raises $40M

#48

Post by j1897 »

RyanHamilton wrote: post #25
AzzieElbab wrote: post #11

Earlier quoted context omitted.

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

Have you checked questdb [1]? the data structure is arrays with data that lands in order and SQL queries on top. The fallback was that it was difficult to deal with out of order data, but we have just solved this by re-ordering data on the fly in memory before it hits the disk. Performance wise probably not far from kdb itself (will be sharing some bench results soon vs open source tsdbs)

NB: I'm one of the co-founder of questdb [1] https://www.questdb.io

Re: TimescaleDB raises $40M

#49

Post by somethingAlex »

halbritt wrote: post #15
somethingAlex wrote: post #10

Very happy with our choice to use TimescaleDB. The idea to simply make it a Postgres extension was brilliant. The compression release was one of the cooler features I've seen in recent times. Row database for recent transactional data, columnar compressed database for historical OLAP workloads - pretty much automagically.

Curious how large a dataset you're using?

Under 100GB; I'm sure vanilla Postgres would suit our needs too. However, adding TimescaleDB on top was not much of an investment and in exchange we got an interface for operations we do often, effortless continuous aggregation, near-constant time appends, and a native way to leave data mutable for a period of time before marking it immutable and compressing it.

The performance is a great feature but its also just an intuitive, familiar (pretty much just SQL) tool that makes life easier.

Re: TimescaleDB raises $40M

#50

Post by throwaway375 »

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 few magnitudes lower disk space. And while Timescale has nice things like materialized views, Clickhouse has them too. And apart from them Clickhouse has excellent data compression algorithms for repeated key value type counters. So it becomes really hard to understand why Timescale. It aims to help you with tables bigger than traditional pg can handle, but at the same time uses same amount of space.
Post reply on HN