I always hear (one of) the argument for ORMs being "If I want to switch databases...", but in reality, after having questioned many many devs, nobody has ever _actually_ done this.
As one of the few devs who has actually switched databases (SQL Server to Postgres) -- without an ORM -- the biggest timesink was regression testing sanely and exporting/importing the data. Which you would have to do with an ORM anyway. The amount of time I spent re-writing a total of ~20 non-ANSI SQL queries and re-creating a handful of views (some of which were quite complex) was no more than 3 hours. And that would have gone by much faster had I been more familiar with Postgres at the time.
> regression testing sanely and exporting/importing the data. Which you would have to do with an ORM anyway
You can export data into ORM specific, database agnostic format, such as Django fixtures or SQLAlchemy fixtures, and test against the ORM. This is actually one of the key ORM features to leverage.
Pretty much ever other django project I work on starts with sqlite, on developers machine and only later gets migrated to PostgreSQL. I'm also dealing with legacy mysql website that didn't use ORM and I really wish they used an ORM. They hard coded column names, relationships, in absolutely most random places. Yes, this could be fixed with having better programmers, but if they used an ORM I could simply ignore a whole class of legacy!
My previous company is actually in the process of switching from Oracle to MySQL. That said doing so is of nightmarish proportions because they have 10-15 years of legacy behind them of building their own ORM, using a modern one and just raw Oracle-SQL (no ANSI joins there!) to either replace, rewrite or drop.