One of the biggest problems with embedding SQL directly into your application is the dreaded vendor lock in. In my experience each RDBMS vendor supports its own special flavor of SQL. Once you've baked that flavor into your code base it becomes non-trivial to change your SQL backend if necessary. From what I understand Amazon has spent years trying to untangle the rats nest of embedded Oracle SQL dependencies within its codebase so it can extract itself from Oracle vendor lock in. So before you bake that SQL string into your code think carefully about what SQL functionality you are using and ask yourself if its representation is specific to your current RDBMS vendor.
Pure ANSI SQL gets you 90% of what most apps need and is portable between MSSQL and Postgres. MySQL/MariaDB are far less ANSI-SQL-compliant, but usually only function calls change when porting.
Nobody sane uses oracle for new development.
If you chose to code your app to MongoDB or Dynamo or whatever you are 100% locked in unless you do a rewrite of your whole data access layer.
To top it off, in the real world you’ll still need a separate SQL DB for reporting and analytics.
