The problem is not that SQL is slow, the problem is people push the system until it becomes slow.

It's just as easy to write 'JOIN this billion row table with that billion row table' as it is to forget how hard that is. We may complain that creating indexes is painful, but take some huge complex and slow query and try recreating it in C++ correctly and at least as fast and you quickly enter a world of pain.

PS: It's awesome to be able to write something and then optimize it without worrying that you are going to break something. When it comes to efficiency being able to select performance trade-offs even in an arcane fashion beats testing everything from scratch by a huge margin.

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.