mpsq

This GitHub repository is just the database, what about the code that holds together their cloud resources? I was not able to find it.

They criticize AWS for making money on Elasticsearch for example, AWS is "taking advantage of the R&D efforts of others". So Amazon is making money on a "serverless" / cloud experience. At the same time, it is known that Amazon is contributing back to Elasticsearch [1]. To that regard, I find their business model really similar to the one AWS is relying upon.

[1] https://www.techrepublic.com/article/aws-contributes-to-elas...

I can't get over the fact that they first say:

"Amazon has a history of offering services that take advantage of the R&D efforts of others: for example, Amazon Elasticsearch Service, Amazon Managed Streaming for Apache Kafka,[...]"

And at the end of the article they promote how they themselves rely on other people hard work:

"TimescaleDB uses a dramatically different design principle: build on PostgreSQL. As noted previously, this allows TimescaleDB to inherit over 25 years of dedicated engineering effort that the entire PostgreSQL community has done to build a rock-solid database that supports millions of applications worldwide."

In the end, it sounds like they are doing exactly what Amazon is doing with open-source.

Everyone seems to be blaming the "bad" (relatively, I personally don't believe that) performance of FF on Gecko. But is that the case? Isn't it mostly because of many websites relying heavily on JS while V8 is much faster than SpiderMonkey? I have been following Phoronix benchmarks for years and where Chrome shines seems to always be on JS benchmarks.

Given that Gecko is probably not the bottleneck, I would consider the decision of halting the project not a bad one. Servo delivered tons of amazing things already, it is a clear success. Maybe Mozilla should consider using V8? After all, losing SpiderMonkey might not be that bad, there is enough "competitors".

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.

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 language is as flexible and efficient as possible for our users.

Thanks for your feedback, I am pleased to know that you like it!

- This is a c5.metal instance (AWS) with 48 physical cores and 192 GB of memory. We use only 24 of those 48 cores.

- If I understand your example well, the query "select * from trips where trip_type = 'Dispatch' and pickup_datetime = '2018-03' and vendor_id = 'VTS';" should be similar. There is no limit in how many filters you can specify in the where clause, it will also have a very minor (if any) impact on the performance.

- Currently yes but this is something we are working on. Out of order insertions is one of our priority and you can expect this to be implemented in a very near future.

- Currently no. However, the way data is stored means that columns are extremely compressible as you mentioned. Our internal API (how we store, access/retrieve columns) would make it easy for us to implement compression, we will do it if this is something important for our users. In the meantime, a filesystem like BTRFS or ZFS would do a nice job (if disk usage is your concern).

- GROUP BY is automatically inferred, users don't need to specify it explicitly, you can find more details about this here: https://questdb.io/docs/sqlExtensions#important-differences-...

EDIT: fix typos