QuestDB co-founder and CTO here - happy to share questdb, a performance-driven open-source time-series database that uses SQL.
High performance databases have a reputation of being inaccessible. They are expensive, closed-source, and require
complex proprietary languages.
We have made our code available under Apache 2.0. Under this new release, QuestDB leverages SIMD instructions, vectorizations and parallel execution to achieve performance figures at the top of the high-performance databases. Results are shown in our blog post.
I sincerely hope that you will find this helpful, and that this will unlock new possibilities! In the meantime, we will carry on working on QuestDB, adding more features, and taking this speed to more query types. Feel free to join us on slack or Github if you want to participate.
I'll have to be careful here as I've no experience either with your DB or Postgres, but comparing questDB with PG and using that to claim it's 100X faster may be technically true but a bit of a dirty trick. It's perhaps like comparing a lorry with an F1 car and being surprised at the winner.
I'm also a little surprised at the speedup using SIMD. If it's RAM constrained, and it clearly is because it scales with the number of memory channels, then I completely fail to understand how instructions - which are bloody fast to execute (SIMD or not) compared to slow RAM access - could benefit you. Both SIMD or not should be waiting on memory AFAICS. Except you clearly do get a big speedup, could anyone enlighten me on this?
1) We didn't compare directly, but our aim is to squeeze as much performance out of hardware as possible to minimize cloud cost. If we are not the best at this right now - we are going to be the best.
2) We are VC funded with 24 months runway. The product is Open Source Apache 2.0 and will remain as such forever. Any future commercial offering will use open source product as a library.
On point 2, I hope you have a good monetisation strategy. I’m a bit wary of new open source databases that don’t have a solid strategy for when their funding runs out, too many times have projects been more or less abandoned after funding ran out, despite being open source (eg Rethinkdb), so I’m rather wary of relying on something until it’s been well established. (Although even basho eventually shut down despite being well established...)
It is hard for me to say right now as we did not benchmark against Clickhouse yet, this is clearly the most requested comparison. We will come back on this!
Thank you for advancing the state of the art!
Do you consider offloading some code to the gpu at some point?
JITs are really good at doing speculative optimization then deoptimizing if the optimization failed.
Couldn't DBs speculatively offload to the gpu (with coherent memory (HSA, etc) access) at least under some constraints/patterns?
Thank you for your kind comment! We would consider offloading to a GPU when the time is right. It feels right to fully utilise CPU capabilities before jumping to GPU.
In the future, we will release other products with features geared towards enterprises. We don't think that having our code open will harm the business.
On the contrary, it will hopefully help us gain some popularity by allowing any developer to access latency levels only seen in trading. We hope that QuestDB will allow them to stop worrying about database performance bottlenecks.
High performance databases have a reputation of being inaccessible. They are expensive, closed-source, and require complex proprietary languages.
We have made our code available under Apache 2.0. Under this new release, QuestDB leverages SIMD instructions, vectorizations and parallel execution to achieve performance figures at the top of the high-performance databases. Results are shown in our blog post.
I sincerely hope that you will find this helpful, and that this will unlock new possibilities! In the meantime, we will carry on working on QuestDB, adding more features, and taking this speed to more query types. Feel free to join us on slack or Github if you want to participate.