IMO this will only appeal to people who don't like SQL or that have a narrow set of problems to solve.
First of all, the number of different dialects is a non-issue because projects that have to send the same queries to different databases are very rare.
Second, in my world where performance matters, you need to hand optimize queries. This is done quite specifically based on the database load and size, let alone specific quirks and strengths of the actual DB product. Something like this would only get in the way.
Third, even if all of these aren't important to you, and you just want to avoid SQL because you don't like it, there are plenty of ORMs in circulation. Many of them allow to specify queries in a fluent fashion.
Finally I think the cardinal issue is expecting that inventing a new dialect will change anything -- imagine the PRQL that compiles to a hundred-lines complex SQL query: would it be necessarily more readable? I doubt it.
And it also rare too switch database vendor mid project, some rare constraints if that happens or if you have too much vc money.
And you should use your database to its full capabilities, including vendor specific queries, otherwise you are just wasting computation. Becuase of this I don't even use query builders anymore, just raw SQL.
"projects that have to send the same queries to different databases are very rare." That's true in business certainly but once you head into academia or are working with medical data / the public sector you often find yourself having to write queries against databases from different vendors to construct datasets, which gets annoying fast. I used to work as an RA in an economic modelling group and hit this issue a few times, so I can see the use of something like this in that niche.
First of all, the number of different dialects is a non-issue because projects that have to send the same queries to different databases are very rare.
Second, in my world where performance matters, you need to hand optimize queries. This is done quite specifically based on the database load and size, let alone specific quirks and strengths of the actual DB product. Something like this would only get in the way.
Third, even if all of these aren't important to you, and you just want to avoid SQL because you don't like it, there are plenty of ORMs in circulation. Many of them allow to specify queries in a fluent fashion.
Finally I think the cardinal issue is expecting that inventing a new dialect will change anything -- imagine the PRQL that compiles to a hundred-lines complex SQL query: would it be necessarily more readable? I doubt it.