Please free us of kdb
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).
TimescaleDB raises $40M
11–20 of 143 posts
Re: TimescaleDB raises $40M
#12Re: TimescaleDB raises $40M
#13Good old HN with its healthy skepticism :)
Re: TimescaleDB raises $40M
#14I'm pretty stoked for this. Timescale ability to use time series on a subset of tables (hypertables) really makes it an interesting choice. I've just dabbled with it but seeing that they'll finally be improving their hosted solution make me want to dive in deeper! Anyone has experience running large DB on timescale, would you recommend it?
A good reference point for this to check out the `multinode` label in their github issues. https://github.com/timescale/timescaledb/labels/multinode
One of the big items that stood out to me is the inability to be able to migrate data from an existing table when creating a distributed hypertable. There were also some significant query performance reports as well.
These all may improve with time of course, so watching the dev cycles will give you a good sense of that I think.
Re: TimescaleDB raises $40M
#15Very 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.
Re: TimescaleDB raises $40M
#16Re: TimescaleDB raises $40M
#17Please free us of kdb
Re: TimescaleDB raises $40M
#18Re: TimescaleDB raises $40M
#19> 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
Founders should have a thick skin when it comes to criticism on HN, because we don't know either.