I feel like you’re imagining that SQL is more of a standard interface than it actually is. No two relational databases are quite the same and you’ll be stuck combing through your entire app looking for obscure syntax usage that depends on Oracle specific extensions or quirks.

There’s no incentive to not extend or try to improve SQL semantics because for proprietary databases it increases lock-in which is good for sales and for OSS databases the extensions are genuinely positive and increase developer productivity and you don’t feel bad about locking your users in because it’s OSS.

I think it is probably easier to port from one SQL dialect to another, than from Mongo’s hokey JSON based query language to anything else.

Also not easy.

We tried to do a migration from Sql Server to Postgres.

Even went as far as building a parser/compiler to transform Sql. Certain things are just too difficult to handle.

1. Sql Server supports arbitrary sql statements in queries. Postgres does not.

2. Data types are not the same.

3. Feature sets at the 'interface edge' between the client library and the engine differ. For example, Sql Server queries can return an arbitrary number of results.

It's true that Mongo uses a custom language, but with Mongo - you are unlikely to have any significant business logic in your data layer.

Also their API surface is relatively simple.

For example, FoundationDB has a layer that mimics the Mongo API. Amazon has one as well.

If you are correct then your consultancy can stand to make hundreds of millions and save companies billions on their Oracle instances!

More likely, though, is that Oracle users use Oracle-specific flavors of SQL in lots of legacy apps that no one wants to touch, and rely on the support contracts for continued assistance in keeping the database performant for its query load.

Because Oracle uses Oracle's flavour of SQL, and no two databases are feature compatible.