j1897

Directly related to your question:

Both victoria metrics and questdb are compatible (ingestion-wise) with the InfluxDB Line protocol, so migration would be smoother than with other databases. Just point the old ingestion script to the new server URL, and data will start flowing in.

Taking a broader view, the time series database landscape is split into three categories (sorry for adding complexity!):

1. Observability (metrics from your hardware): Prometheus, and other engines that work well with Prometheus such as Victoria Metrics. I think their language is tightly coupled with PromQL. InfluxDB 1.X and 2.X used to be in this camp and were the market-leading solution for observability before Prometheus came along and got incredible adoption. Chronosphere built with m3db is also a big name in this category.

2. General purpose: TimescaleDB is built on top of Postgres, and is now seen increasingly as a super postgres that can also deal with time series data, amongst other things (now focusing on vectors as well).

3. Specialized: kdb+, QuestDB, some OLAP databases that can also do time series (Clickhouse & Druid), and perhaps InfluxDB 3.0 even though it's not OSS yet. Here the focus is on performance, and the data loads tend to be more significant. Industries and use cases often paired with demanding data loads, such as financial services, often require such specialized databases. Some have their prop language (kdb+ with Q), some are closed source (kdb+), and others are OSS & use SQL (questdb, clickhouse, druid). InfluxDB 3.0 also uses SQL (from DataFusion's query engine) but is not OSS yet.

Super cool! Visually dazzling.

If you want to build something similar on a raspberry pi, here is a tutorial: https://questdb.io/blog/create-flight-radar-raspberry-pi-que...

Thanks for the kind words and your perspective !

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

QuestDB (YCS20) | Remote | Full-time| Senior Cloud Engineer

Hi all! At QuestDB, we have built the fastest open source time series database from the ground up to offer breakthrough performance for real-time analytics using SQL. We bring experience and technical approaches from low-latency trading to leverage real-time data processing in various use cases and industries. Our users deploy QuestDB to make time series analysis fast, efficient, and convenient in financial services, IoT, application monitoring, and machine learning.

We are a remote-first company based in London and SF, backed by leading venture capital firms and Y Combinator. We are hiring for the following roles:

Senior cloud engineer: https://questdb.io/careers/senior-cloud-engineer/ Head of Developer Relations: https://questdb.io/careers/head-of-developer-relations/ Front end engineer: https://questdb.io/careers/front-end-engineer/

QuestDB is open source and will remain so forever. You will be able to scale with it. Our commercial product, Pulsar, uses QuestDB as a library and will offer enterprise integration and monitoring features, which are typically required for massive enterprise deployment.

To answer your question, it will depend how big of a scale we are looking into. If you are a large company running questdb throughout the organization and need a specific feature set to do so, you will probably be looking to get our paid offering.

Sure could you join our slack ? Top right of our website www.questdb.io

Hey, one of the key differences here is that Clickhouse is owned by a large corporation, Yandex (the Google of Russia) and seems to drive its roadmap in function of the needs of the company. We are committed to our community and driving our roadmap based on their needs rather than having to fulfill needs of a parent company.

Ultimately as a result we think that questDB will be a better fit for your community. We acknowledge that Clickhouse has lot more features as of now being a more mature product.

if you click on join slack top right of our website you'll be joining our public channels!

Not yet - there is a bench vs clickhouse that has been done by one of their contributor though see below in the comments.

Hard question to answer because each solution is unique and has its own tradeoffs. Taking a step back QuestDB is a less mature product than the ones mentioned, and therefore there are many features, integrations etc. to build on our side. This is a reflection of how long we have been around and capital we have raised versus those companies who are much larger in size.

We've had one of their contributors bench questdb versus Clickhouse recently - you can find the results here https://github.com/questdb/questdb/issues/436

This came from a bench we had on our previous website versus them about summing 1 billion doubles.

hi there - co-founder of questdb here. The demo on our website hosts a 1.6 billion rows NYC taxi dataset with 10 years of weather data with around 30-minute resolution and weekly gas prices over the last decade.

We've got example of queries in the demo, and you can see the execution times there.

We have posted a blog post comparing the ingestion speed of InfluxDB and QuestDB via InfluxDB Line Protocol some time ago: https://questdb.io/blog/2019/12/19/lineprot

hi, co-founder of QuestDB here.

QuestDB is open source and therefore free for everybody to use. Another product using QuestDB as a library with features that are typically required for massive enterprise deployment will be distributed and sold to companies through a fully managed solution.

Our idea is to empower developers to solve their problems with QuestDB open source, and for those developers to then push the product within the organisation bottom up.

Timescale is built on top of Postrgres. QuestDB has been built from the ground up. Both are SQL. QuestDB is primarily focused on performance while timescale has more features today.

We ran this experiment Vs influx some time ago for ingestion here https://medium.com/questdb/speeding-up-influx-line-protocol-...

In terms of queries, see our previous post on HN to get a sense https://news.ycombinator.com/item?id=22803504

Hi! The performance gap between questDB on both ingestion and queries versus timescale or influx is very significant (orders of magnitude faster). questDB is being used in production for critical use cases at large companies and is definitively stable. Watch out for our new release next week

Under the hood is a stack written from scratch without any dependencies - all libraries have been rewritten. It's in boring Java (zero-GC) and C++ for high performance components such as SIMD instructions. The idea being to provide massive performance and accessibility through SQL. IoT/monitoring being one of the use cases that work particularly well for questdb

don't hesitate to join our slack and ask us any question you have

co-founder of questdb here - we have been asked the same question on reddit as well. We are starting to work on an article going through a comparison between QuestDB and Clickhouse today - this will also include a bench. Will share as soon as we can. stay tuned!

QuestDB | Technical Content writer + head of Dev Rel |Remote, London/SF

QuestDB is a an open source SQL database to process time-series, faster. The founding team comes from low-latency trading; fast software are part of our DNA. Through QuestDB, companies can harness the power of real-time and big data processing in a wide array of use cases and industries, from financial data to IoT and connected cars.

We have to just raised $2.1m from leading European VCs and are building the team.

Helping developers solve their problems is at the center of what we do. We are looking for a head of developer relation and technical content writer and to spur developer adoption and usage, grow the brand and empower developers with faster software.

https://angel.co/company/questdb/jobs/760919-technical-conte... https://angel.co/company/questdb/jobs/745625-head-of-develop...