Shades of Basho (rip). One wonders if there is a curse on open source database companies. Maybe we could call it Data Gravity?

I'm wondering if it would be worth skipping the SQL layer and compiling straight to the execution plan level. This would make PRQL tightly coupled to a database, but would also unlock performance and fine-tuning potential. And, maybe it would be possible to run it inside the database process, enabling data processing right at the source.

(eg. in Postgres, this would be more or less a replacement of the PREPARE statement.)

Beyond being closed source, SingleStoreDB's License explicitly prohibits benchmarking:

https://www.singlestore.com/assets/contracts/singlestore-fre...

2. Restrictions. You acknowledge that the Software, and its structure, organization, and source code, constitute SingleStore’s and its suppliers’ valuable trade secrets, and the Software is subject to the following restrictions. Specifically, Customer shall not, and shall not ... conduct any competitive analysis, publish or share with any third party any results any results of any technical evaluation or benchmark tests performed on the Software, or disclose Software features, errors or bugs to a third party without SingleStore’s prior written consent (“Benchmarking”); or

FWIW Mysql 8 has gotten a lot better in standards compliance and ironing out legacy quirks, with some config tweaks. While my heart still belongs to PostgreSQL things like no query hints, dead tuple bloat (maybe zheap will help?), less robust replication (though getting better!), and costly connections dampens my enthusiasm.