> 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.
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?