I think they have this perspective because SQLite is almost never mentioned when DBs are discussed. Almost everyone pushes postgres, which I think is often a bit insane. Postgres or (often rarely) MySQL is given as the answer to most DB questions, even when coming from clearly new devs. It's not often that the dev needs any of the large amount of setup/permissions required for postgres/MySQL. The fact that SQLite comes as part of python's standard library should be used as second nature for most devs. I feel the same way - that SQLite should be the default answer, and one should reach towards postgres or MySQL unless you really *have* to.

SQLite is not meant to compete directly with MySQL or Postgres. It's meant for local usage only, where you don't need high concurrency, managing multiple connections, replication, etc.

I mean, you could probably use SQLite in many simple cases which currently use Postgres (personal servers, small apps), but advocating it as default solution is inadequate at best, if not misleading to people starting out in the field.

What? SQLite is rarely the answer to replace Postgres or MySQL... it is not designed for network access nor high availability.

Most of the answers I was referring to are miles away from those requirements. Postgres fanbois love to suggest it for everything - for which ahuge percentage of the time is simply 'This csv is too big, how do I load part of it?'.

The suggestion of Postgres is very often not required, because there isn't a need for multiple users, different permissions, password protection, etc.