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

Launch HN: QuestDB (YC S20) – Fast open source time series database

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 173 posts

Re: Launch HN: QuestDB (YC S20) – Fast open source time series database

#51

Post by gregwebs »

I am still hoping to see comparisons to Victoria Metrics, which also shows much better performance than many other TSDB. Victoria Metrics is Prometheus compatible whereas Quest now supports Postgres compatibility. Both have compatibility with InfluxDB.

The Victoria Metrics story is somewhat similar where someone tried using Clickhouse for large time series data at work and was astonished at how much faster it was. He then made a reimplementation customized for time series data and the Prometheus ecosystem.

Re: Launch HN: QuestDB (YC S20) – Fast open source time series database

#52

Post by shay_ker »

mpsq wrote: post #32
shay_ker wrote: post #12

Absolutely love the story. TimescaleDB & InfluxDB have had a lot of posts on HN, so I'm sure others are wondering - how do we compare QuestDB to them? It sounds like performance is a big one, but I'm curious to hear your take on it.

As you said, performance is the main differentiator. We are orders of magnitude faster than TimescaleDB and InfluxDB on both data ingestion and querying. TimescaleDB relies on Postgres and has great SQL support. This is not the case for InfluxDB and this is where QuestDB shines: we do not plan to move away from SQL, we are very dedicated in bringing good support and some enhancements to make sure the querying languag…

I'm sure many folks would be really interested to see two things:

1. A blog post around a reproducible benchmark between QuestDB, TimescaleDB, and InfluxDB

2. A page, like questdb.io/quest-vs-timescale, that details the differences in side-by-side feature comparisons, kind of like this page: https://www.scylladb.com/lp/scylla-vs-cassandra/. Understandably, in the early days, this page will update frequently, but that level of transparency is really helpful to build trust with your users. Additionally, it'll help your less technical users to understand the differences, and it will be a sharable link for people to convince others & management that QuestDB is a good investment.

Re: Launch HN: QuestDB (YC S20) – Fast open source time series database

#55

Post by avthar »

shay_ker wrote: post #52
mpsq wrote: post #32

Earlier quoted context omitted.

As you said, performance is the main differentiator. We are orders of magnitude faster than TimescaleDB and InfluxDB on both data ingestion and querying. TimescaleDB relies on Postgres and has great SQL support. This is not the case for InfluxDB and this is where QuestDB shines: we do not plan to move away from SQL, we are very dedicated in bringing good support and some enhancements to make sure the querying languag…

I'm sure many folks would be really interested to see two things: 1. A blog post around a reproducible benchmark between QuestDB, TimescaleDB, and InfluxDB 2. A page, like questdb.io/quest-vs-timescale, that details the differences in side-by-side feature comparisons, kind of like this page: https://www.scylladb.com/lp/scylla-vs-cassandra/ . Understandably, in the early days, this page will update frequently, but tha…

Perhaps the QuestDB team could add it to the Time Series Benchmarking Suite [1]? It currently supports benchmarking 9 databases including TimescaleDB and InfluxDB.

[1] https://github.com/timescale/tsbs

Re: Launch HN: QuestDB (YC S20) – Fast open source time series database

#57

Post by mpsq »

avthar wrote: post #55
shay_ker wrote: post #52

Earlier quoted context omitted.

I'm sure many folks would be really interested to see two things: 1. A blog post around a reproducible benchmark between QuestDB, TimescaleDB, and InfluxDB 2. A page, like questdb.io/quest-vs-timescale, that details the differences in side-by-side feature comparisons, kind of like this page: https://www.scylladb.com/lp/scylla-vs-cassandra/ . Understandably, in the early days, this page will update frequently, but tha…

Perhaps the QuestDB team could add it to the Time Series Benchmarking Suite [1]? It currently supports benchmarking 9 databases including TimescaleDB and InfluxDB. [1] https://github.com/timescale/tsbs

This is a great idea, we will have a look! It is good to see that the ecosystem is moving towards a normalized / "standard" benchmarking tool.

Re: Launch HN: QuestDB (YC S20) – Fast open source time series database

#58

Post by biztos »

bluestreak wrote: post #50
judofyr wrote: post #46

Congratulations on launching! It looks like a great product. Some technical questions which I didn’t see answered on my first glance: (1) Is it a single-server only, or is it possible to store data replicated as well? (2) I’m guessing that all the benchmarks were done with all the hot data paged into memory (correct?); what’s the performance once you hit the disk? How much memory do you recommend running with? (3) Ho…

thank you! - replication is in the works, this is going to be both TCP and UDP based, column-first, very fast. - yes, benchmarks are indeed are done on second pass over the mmaped pages. First pass would trigger IO, which is OS-driven and dependant on disk speed. We've seen well over 1.5Gb/s on disks that support this speed. Columns are mapped into memory separately and they are lazy accessed. So the memory footprint…

Definitely enjoyed the story and I find the product interesting! I especially like the time-series aggregation clauses since it makes it easy to "think in SQL."

I was also going to ask about replication. Any idea when it's going to be done?

Oh and kudos for the witty (previous) company name: Appsicle, haha, love that.

Re: Launch HN: QuestDB (YC S20) – Fast open source time series database

#60

Post by patrick73_uk »

biztos wrote: post #58
bluestreak wrote: post #50

Earlier quoted context omitted.

thank you! - replication is in the works, this is going to be both TCP and UDP based, column-first, very fast. - yes, benchmarks are indeed are done on second pass over the mmaped pages. First pass would trigger IO, which is OS-driven and dependant on disk speed. We've seen well over 1.5Gb/s on disks that support this speed. Columns are mapped into memory separately and they are lazy accessed. So the memory footprint…

Definitely enjoyed the story and I find the product interesting! I especially like the time-series aggregation clauses since it makes it easy to "think in SQL." I was also going to ask about replication. Any idea when it's going to be done? Oh and kudos for the witty (previous) company name: Appsicle, haha, love that.

Hi, I'm a questdb dev working on replication, we should have something working within a couple of months. If you have any questions feel free to ask me.
Post reply on HN