Maybe you have a lot of busy tests and you can get feedback twice as fast using less RAM on a SQLite memory database on your laptop, which is not a maxed-out current model, and you know that every commit you push will go through a CI build which uses the same database as production.
Maybe you are consciously trying to avoid locking your project into one database accidentally.
Maybe you work in an enterprise environment where you can’t run Docker or network services on your local system.
Maybe you know that your CI process will run against more data than fits on your laptop and so you’re not worried about missing something.
My point wasn’t that you shouldn’t test in the same environment but that it’s too quick to say that because you have never had this need nobody else does either.
> Maybe you are consciously trying to avoid locking your project into one database accidentally.
People keep bringing this up, but for applications (not libraries), how many times has this mattered (for FOSS DBs), and how many times has upholding agnosticness required weird hacks or limited something?
The reason people bring it up is that it's real for some people, even if it's not a universal requirement. Anyone who sells software has customers who have standardized on one database. Some places have senior management wanting to avoid lock-in (Oracle migrations will almost always be mentioned in this case) and may have pressure or outright requirements — and if you're a contractor working for them this will be written into their requirements. Some products have a demo/lite mode to make it as easy as possible to try – e.g. SonarQube can run in a single container (with prominent warnings that your database is not persistent) just to make it easy for someone to try it.
It's certainly not the most common and I would definitely seriously question it if you know you're going to benefit from a Postgres-specific feature (the last big Django project I started used JSONField and several other features heavily), but the world is a big place and there are many features which only some people use but it's critical for them. This discussion reminds me a lot of when people would question why you need a localization framework because they've never used one.
Why would you make dev/prod parity a whole lot worse just to make your tests perhaps marginally faster?