Please free us of kdb
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
TimescaleDB raises $40M
61–70 of 143 posts
Re: TimescaleDB raises $40M
#62Earlier 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...…
Everything works reasonably well in a relational database if your data is small. As you scale up, the performance will fall off a cliff for any data model that the internals of the database kernel were not specifically designed for. No relational database kernel is optimized for time-series data models, so poor performance is just a matter of scale.
Re: TimescaleDB raises $40M
#63Congrats!
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?
Re: TimescaleDB raises $40M
#64Earlier quoted context omitted.
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…
Cool. I'm keen to try it. Wondering how well it works with multi-terabyte data sets.
Re: TimescaleDB raises $40M
#65Earlier 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...…
This is a thought exercise I've done myself, and your questions will mostly be answered by looking at the features (https://docs.timescale.com/api/latest/) that TimescaleDB provides.
> However, this basically means a compressed column store, which again, doesn't really have much to do with time.
It does though: which data do you compress? The old data. Why not let the database figure that out for you, so you don't specifically have to tell it.
Other features include:
- Continuous Aggregates: a materialized view aggregating data over time is doable, but why not let the database materialize it for you, and automatically fall back to an un-materialized query for the newest data?
- Retention: deleting (or downsampling) old data is easy to do on your own, but why not let the database do it for you according to a policy?
Re: TimescaleDB raises $40M
#66I 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 fe…
Did you turn on compression in TSDB?
I checked documentation and I don't think I did. Looks like it has same compressing algorithms as Clickhouse, so it should be pretty close in space requirements for old chunks.
Re: TimescaleDB raises $40M
#67> 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.
Because VHS was better in multiple regards.
Re: TimescaleDB raises $40M
#68> 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
To be fair, the skepticism wasn't without merits given the lengths TimescaleDB goes to make timeseries work. From their blog entries [0][1], it is evident that they essentially shoe-horn techniques from columnar stores like Apache Druid / Kudu, and file-types like Apache ORC / Parquet into Poatgres' row-based data-model. Reminds me of BigTable / HBase, in a way, too.
TimescaleDB's biggest feat here is of course pulling the engineering magic rabbit out of the hat by chipping away at it for 4+ years, and effectively answering the skepticism by delivering on their promise.
Note though, Amazon Redshift is built on Postgres, and (allegedly) so is Amazon Timestream.
[0] https://blog.timescale.com/blog/building-columnar-compressio...
[1] https://blog.timescale.com/blog/time-series-compression-algo...
Re: TimescaleDB raises $40M
#69Earlier quoted context omitted.
He's probably referring to OSIsoft's PI historian.
Their stuff is a nightmare to use, and is insanely expensive. Always nice when we get to just swap it out for something like Canary or even Ignition although folks are always trying to trash the Ignition Historian when it works well for most use cases people need to solve.
Yeah, Ignition’s historian isn’t meant to replace or compete with PI, it’s just meant to provide a basic historian that meets the average user’s needs.
Re: TimescaleDB raises $40M
#70TimescaleDB 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…
Timescale Co-founder here. Happy to address your concerns!
1. Monetization strategy
This funding round is actually a sign that our business model is working really well.
To quote Redpoint Ventures, who led this funding round:
"The [Timescale] team capitalized on their significant community momentum last year, with their cloud business being one of the fastest-growing database businesses we have seen in the past 20+ years." [0]
Most companies (including open-source companies) actually have both open-source and proprietary software, but the proprietary software is often hidden inside private repos. The difference with Timescale is that we have made the source code for our proprietary software available (on Github), even allowing users to modify it (eg "right to repair), and made all of our software free (ie no paid software features). [1]
3. Public product roadmap
We aim to be transparent re: product roadmap via Github, blog posts, etc, but I appreciate the feedback that we could be more transparent. Thanks!
4. Version compatibility / broken APIs
Could you say more? AFIAK the only time we "broke" (ie changed) some APIs is with TimescaleDB 2.0, and when we did so we explained why we did that (mostly to improve user experience based on feedback). We take this topic very seriously and even the decision to do so in 2.0 was not something we did lightly (and it was also made after a lot of discussion with users). More about this decision here in our docs: [2]
5. Commercial support for on-premise
We offer free support for on-premise instances via Slack (where you can often find our engineers, support team, CTO, and myself). [3] However, if you would like a higher level of support for on premise (e.g., commercial SLAs), please reach out to us directly (e.g., via the form on that same page). [3]
Hope this helps!
[0] https://medium.com/redpoint-ventures/building-a-next-generat...
[1] https://blog.timescale.com/blog/building-open-source-busines...
[2] https://docs.timescale.com/timescaledb/latest/overview/relea...