It’s not clear from the paper or their website how it works, the paper seams to talk about an optimizer where the websites states its AI maybe this is just slop. Hard to determine when skimming it, although seams like a neat idea if it’s a proper engine and not just AI that anyone could copy and paste into a chat with the statistics.
Hello, paper co-author here.
QueryBrew is based on our research relational database Umbra (https://umbra-db.com/) which has been in development since around 2018.
Our optimizer needs to produce correct plans within milliseconds while considering thousands to millions of alternatives, so using machine learning based approaches is often not a great fit. We instead rely on purpose-built algorithms like query decorrelation (https://15799.courses.cs.cmu.edu/spring2025/papers/11-unnest...) and DP based join ordering (https://dl.acm.org/doi/pdf/10.1145/3183713.3183733).
We have used AI for fuzzing input queries to test the optimizer.
> Approach. QueryBrew builds a refined SQL statement by passing
an input query through Umbra’s [11] state-of-the-art optimizer
and distilling the resulting optimized plan back into SQL
We haven’t decided that—Substrait[0] is still the IR for query plans across different execution engines—but projects like QueryBrew are a great side effect of what a SOTA planner can accomplish.
Quite a cool concept. Seems that things are finally on the edge of moving again in database land (e.g. postgres is great but it's quite old)
It’s not clear from the paper or their website how it works, the paper seams to talk about an optimizer where the websites states its AI maybe this is just slop. Hard to determine when skimming it, although seams like a neat idea if it’s a proper engine and not just AI that anyone could copy and paste into a chat with the statistics.
Hello, paper co-author here. QueryBrew is based on our research relational database Umbra (https://umbra-db.com/) which has been in development since around 2018. Our optimizer needs to produce correct plans within milliseconds while considering thousands to millions of alternatives, so using machine learning based approaches is often not a great fit. We instead rely on purpose-built algorithms like query decorrelation (https://15799.courses.cs.cmu.edu/spring2025/papers/11-unnest...) and DP based join ordering (https://dl.acm.org/doi/pdf/10.1145/3183713.3183733). We have used AI for fuzzing input queries to test the optimizer.
Thank you for clarifying, sounds a lot better then my initial impression!
> Approach. QueryBrew builds a refined SQL statement by passing an input query through Umbra’s [11] state-of-the-art optimizer and distilling the resulting optimized plan back into SQL
What website are you talking about? This has nothing to do with AI.
https://querybrew.db.cit.tum.de/
I was looking at the wrong thing when I searched, this came up: querybrew dot com.
Very practical approach to “query optimizer as a service”, but I find it cursed that we have decided SQL is the IR for databases
We haven’t decided that—Substrait[0] is still the IR for query plans across different execution engines—but projects like QueryBrew are a great side effect of what a SOTA planner can accomplish.
[0]: https://substrait.io