One particular thing I have noted is some of the databases have a "_take everything I have_" design that works very well for a single-user, one-query-at-a-time workload but often falls flat when there are multiple concurrent users in the system and you do not want one single large query to hog all the resources. This former approach makes sense for databases like DuckDB that are meant to be run on your laptop. It's just one user running queries on their computer unless the kids in the family know how to run SQL queries 🙂 , But that's not a typical workload in production. To get a sense of real-world performance, I would also recommend a concurrent workload that runs for a while.
In addition, in your production deployment, you will want to reserve ingestion capacity isolated from query load, something that Druid assumes even on a single node. That nuance is often missed by the person running the benchmark.
All that said, do let us know what you find and if there are gaps. We are constantly looking to improve. In the long run, the databases that win are the ones that are receptive to community feedback. Everything else is secondary (not that we are not good at those secondary things ). We have a lot of cool stuff coming in 2024, and any feedback from the community will help us point that roadmap in the right direction.