django-pgware is the successor to django-pglocks, and it absorbs two siblings on the way: django-pg-set (temporarily setting GUCs) and pg-hush-django (keeping sensitive query parameters out of the logs). Three small single-purpose packages I’d maintained separately are now one distribution, one version, one test matrix. The import root stays django_pg_utils, so existing call sites change a prefix and nothing
I love Django a lot; it still surprises me how productive I can be in it. And, especially in more recent versions, the error handling for weird configuration problems is much, much better than it used to be.
But sometimes, you get an error whose origin is slightly mysterious. Thus, it can be helpful to have a log of
You can’t build a real-life system without caching.
That being said, it’s often the case that parts of the system you think are going to be slow aren’t. I’ve noticed a tendency to build out a huge stack of components (“we’ll have PostgreSQL, and Redis, and Celery, and Varnish, and…”) without actually measuring where the bottlenecks are.