I think we don't see companies switching databases because it would be a pain to support the transition. There are implementation specific features that could be used that would break on a switch. Then migrating all of the data and stored procs/functions/views/etc would be a pain too as they would need to be updated for the syntax of the new database. Simple things like TOP in T-SQL do not exist in other database implementations, so that is a simple thing that would have to be fixed. Other things like CROSS APPLY in T-SQL do not (to the best of my limited knowledge) exist in other RDMS, so that would be a more complicated re-write.
LIMIT/TOP is a good example actually of the sort of thing that every ORM I've used is great at covering between databases. I haven't seen any ORMs that support queries with sophisticated JOINs, much less CROSS APPLY/CROSS JOIN LATERAL.
But I would agree that, if you're using the more complex stuff like custom functions, stored procs, triggers, etc, you're much more likely to get tripped up by that switching between databases, though ORMs mostly don't touch that kind of stuff.
Anyways, my point was that it wouldn't be ORM support or tied to ActiveRecord that would prevent a business from switching databases but a whole lot of other work that would need to go on.
select a.username, p2.*
from accounts a
join posts p2 on p2.id in (select p1.id from posts p1 where p1.account_id = a.id order by p1.score desc limit 2);
The active record pattern, where you have objects like RoR's ActiveRecord or Django's Model that directly wrap a row in a table in a database, has a nasty hidden trap that rears its head once your app is complex enough.
By tightly coupling your database backend to your application models, it all but guarantees you can't switch to another database without a major rewrite of your application.
This is probably why you don't see companies switching databases. They can't.