Comment by chaxor
4 years ago
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.
This view is the view I was talking about in the op.
Inadequate for what? Most persistence layers I've ever seen did not need MySQL, postgres or MongoDB.
> high concurrency, managing multiple connections, replication
In the grand scheme of things, basically nobody needs these things. Sorry, your app is overengineered.
Your app actually suffered in areas such as performance, security, portability, complexity and cost.
Developers love to prematurely optimise everything. Most SaaS products today don't need a dedicated database server. Most apps that require a database server backend would be better with sqlite, most Dev/test/staging/prod pipelines would be better served with sqlite files.
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.