6👍
Any time the query generator might produce queries that behave differently on different platforms despite the efforts of the query generator’s platform abstractions. Differences in regular expressions, collations and sorting, different levels of strictness about aggregates and grouping, use of full-text search or other extension features, use of anything but the most utterly simple functions and operators, etc.
Also, as you noted, any time you run raw SQL.
It’s moderately reasonable to run tests on SQLite during iterative development, but you really need to run them on the same DB you’re going to deploy on before you push to production. Otherwise you’ll get bitten by some query where different engines have different capabilities to prove transitive equality through joins and GROUP BY or are differently permissive of queries, so a query will work on one then fail on the other.
You should also test against PostgreSQL on a reasonable data set before pushing changes live in order to find obvious performance regressions that’ll be an issue in production. It makes little sense to do this on SQLite, where often totally different queries will be fast or slow.
I’m surprised you’re seeing the kind of speed difference you report. I’d want to look into why the tests run so much slower on PostgreSQL and what you can do about it, since in production it’s clearly not going to have the same kind of performance difference. I wrote a bit about this in optimise PostgreSQL for fast testing.
2👍
The performance characteristics will be very different in most cases. Often faster. It’s typically good for testing because the SQLite engine does not need to take into account multiple client access. SQLite only allowed one thread to access it at once. This greatly reduces a lot of the overhead and complexity compared to other RDBMSs.
As far as raw queries go, there are going to be lot of features that SQLite does not support compared to Postgres or another RDBMS. Stay away from raw queries as much as possible to keep your code portable. The exception will be when you need to optimize specific queries for production. In those cases you can keep a setting in settings.py to check if you are on production and run the generic filters instead of a raw query. There are many types of generic raw queries that will not need this sort of checking though.
Also, the fact that a SQLite DB is just a file, it makes it very simple to tear down and start over for testing.
- [Django]-How to create template tags in django and use Form?
- [Django]-A simpler i18n for Python/Django
- [Django]-Adding a **kwarg to a class