Django's ORM doesn't stop you from using database-specific features (JSON fields, full text search, PostgreSQL's geo extensions, etc.) It also makes it very straightforward to bypass parts of the ORM and write your own SQL either just as the WHERE part of a query or as the whole SQL statement. If you build a large enough app that deals with enough data, you'll eventually find some hot spots where you need to do that for performance reasons. When you do that, you obviously can lose portability.

If you avoid those things though, you pretty much can switch the database. In practice, I've never really found a need to do that for a production system, but it still has some major advantages. First, I regularly run PostgreSQL in production, but I can use SQLite as an in-memory database for unit tests, which makes those much faster (and simpler to run unit tests without having to also spin up a full DBMS).

The other huge advantage is that it enables Django's whole ecosystem of reusable applications. Eg, the built-in admin interface, popular third party applications for authentication, tagging, CMS-type stuff, etc. are generally written using the ORM and as a result can be added to any Django project with a couple lines of config and will work no matter what database you use. That large ecosystem of fairly polished components has been a major reason that Django has remained so popular for such a long time. If it had to be split up by supported database ("MySQL admin" vs "PostgreSQL admin", etc), I don't think it would've been as successful.

Most of the databases I access are from external providers. We changed our main provider 2 years ago, so their DB went from Oracle to SQL Server.

So in 12 years that would have been one database change. Except all the schema has changed and they don't allow SQL queries on it but provide good old SOAP web services...

So even if I had used a full ORM (I use Dapper, you write the SQL, it "just" converts the result of the query to objects) I still would have to change my code to adapt to the new provider.

However going from SQL to webservices really convinced me SQL is a superpower. With it you get exactly the data you need, no need to re-process it in code.

Before this change I never had to really look at my apps performances, it was good enough. But since this provider webservices are so inefficient (for example I can't "query" a single customer, I have to get all of them) I had to optimize my app in every possible way to mitigate these inefficiencies.

I assume it would be a bit easier because the query and ORM syntax is uniform across databases. And it also probably wont support many database-specific operations.

But it would still be work. Some databases don’t support basic operations (e.g. UPDATE with LIMIT in postgres) which you can still do with the query syntax. And different databases usually have different preferred (usually faster) ways of doing indexes, joins etc. Plus you still have to migrate your data.

ORMs are ideally supposed to be a complete abstraction where you can pretend the database doesn’t exist, so if you switch it shouldn’t matter. The problem in, in practice you can’t pretend the database doesn’t exist. So you either end up writing code for your specific dialect anyways, or you write inefficient code.

It’s also like, you can just write plain SQL and ignore your dialect’s extra features. And that would make migration much easier, but it would also be less efficient and much harder to write.