The problem is that most SQL engines have commands for fine-tuning. Things like 'ignore index', for instance. That is a leaky abstraction - knowing the details of the system lets the programmer do better than the query analyzer. Similarly, sometimes a left join + null check performs better than a "where not exists ()" subquery, despite them serving identical purposes.
If you can change how you phrase a query and get different performance, while keeping the same semantic meaning, your language isn't just leaking, it's hemorrhaging. It may still be useful, perhaps world-changingly so, but it's a perfect example of the dangers of declarative programming.
As to 'try making it in C++': with a library for doing so with as much maturity as SQL? Sure. It'd probably be reasonably simple, if more verbose. And when it inevitably runs slowly, you can infer the reason for why A runs faster than B relatively simply, because it's doing precisely what you told it to do.
If you can change how you phrase a query and get different performance, while keeping the same semantic meaning, your language isn't just leaking, it's hemorrhaging. It may still be useful, perhaps world-changingly so, but it's a perfect example of the dangers of declarative programming.
As to 'try making it in C++': with a library for doing so with as much maturity as SQL? Sure. It'd probably be reasonably simple, if more verbose. And when it inevitably runs slowly, you can infer the reason for why A runs faster than B relatively simply, because it's doing precisely what you told it to do.