1. Create covering indexes sorted by each column to be searched.
2. Enable sqlite_stat4
3. Use WAL mode.
4. Set a busy_timeout
5. Vacuum and analyze daily.
6. Nobody has heard of Jango.
Vacuum & Analyze are two fun ones and I think postgres in particular would do well by investing a bit more into the default configuration of autovacuum since the out of the box settings are pretty conservative compared to the state most out of the box DBs are used - but I think that DB configuration is very much an unsolved problem in general and can be a quite surprising source of major performance gains (or losses!).
I mentioned mat views elsewhere - but if you are really hitting quite predictable usage patterns (where covering indexes are stable enough) then some well defined mat views might go a long way to tuning performance that little bit more - just be aware of the fact that rematerialization isn't instantaneous and if you have a high rate of change in the data then you'll probably want time based re-materialization instead of trigger based which means you'll need to account for some inconsistent data (as is the case with caching in general).
SQLite doesn't have materialized views.
It's the best kept secret on the internet. I wish you guys blogged about your engineering, I bet there's lots to say.
Keep rocking
So are you actually a paying customer with a Radio Airplay account or are you a free Jango listener? I never had and never needed an account.
I don't know what kind of database Jango uses or what kind of work Jango people do but I sure hope they keep doing it.