Substituting a different database for testing purposes is right up there with trying to mock the database, in my book.
It places big constraints on your development, because you get stuck limiting yourself to the subset of SQL that is supported by both databases. That usually means trapping yourself in the 1990s, which, given everything that been implemented in the major RDBMSes over the past 20-25 years, implies accepting an artificially low ceiling on the performance, and possibly the semantics, that you can get out of your data store.
Second, even if you're fine with sticking to a small subset of your database's features, you're still not guaranteed that the two DBMSes will behave the same way given the same input. This is particularly true if one of them is SQLite, which is dynamically typed.
With the possible exception of key/value stores, databases generally exhibit such complex behavior that, if you're looking to conclusively verify that logic involving your database actually works, you probably shouldn't accept any substitutes.
I would argue that sticking to 1990's sql is good anyway as it means the business can switch to a different engine. There are several great databases out there with support, if you limit yourself to standard sql you can throw our your current vendor if they don't give you enough value (which could be support, speed, or even the salesman beats you in golf)
I understand sometimes the extensions are worth using, but good engineering is to limit those uses to where it actually is significant.
If you're looking for the ability to switch data storage technologies, you'd do better to just make sure your data storage layer is cleanly isolated.
Sticking to 1990s SQL gives you the ability to swap among 5 or 6 different databases, all of which have been around for a day or two, none of which have seen a whole lot of change in their relative strengths and weaknesses in a good long while. It's just not super likely that you'll find a compelling reason to switch among them, especially if the people who made the original choice did their homework first.
Keeping a well-isolated data layer, on the other hand, gives you a much wider universe of things you can attainably switch to - document stores, triplestores, graph DBs, Cassandra, Hadoop/Hive, stuff that hasn't been invented yet, etc. I've lived through my fair share of database technology migrations.
So far, every single one of them has been this kind, not a SQL -> SQL migration. So, while you're at it, might as well get your money's worth out of the SQL DB.
It places big constraints on your development, because you get stuck limiting yourself to the subset of SQL that is supported by both databases. That usually means trapping yourself in the 1990s, which, given everything that been implemented in the major RDBMSes over the past 20-25 years, implies accepting an artificially low ceiling on the performance, and possibly the semantics, that you can get out of your data store.
Second, even if you're fine with sticking to a small subset of your database's features, you're still not guaranteed that the two DBMSes will behave the same way given the same input. This is particularly true if one of them is SQLite, which is dynamically typed.
With the possible exception of key/value stores, databases generally exhibit such complex behavior that, if you're looking to conclusively verify that logic involving your database actually works, you probably shouldn't accept any substitutes.