<p>I tend to use <a href="http://en.wikipedia.org/wiki/SQLite" rel="noreferrer">SQLite</a> when doing <a href="http://en.wikipedia.org/wiki/Django_(web_framework)" rel="noreferrer">Django</a>
development, but on a live server something more robust is
often needed (<a href="http://en.wikipedia.org/wiki/MySQL" rel="noreferrer">MySQL</a>/<a href="http://en.wikipedia.org/wiki/PostgreSQL" rel="noreferrer">PostgreSQL</a>, for example).
Invariably, there are other changes to make to the Django
settings as well: different logging locations / intensities,
media paths, etc.</p>

<p>How do you manage all these changes to make deployment a
simple, automated process?</p>

Update:
django-configurations
has been released which is probably a better option for most people than doing it manually.
If you would prefer to do things manually, my earlier answer still applies:
I have multiple settings files.
```
settings_local.py
```
- host-specific configuration, such as database name, file paths, etc.
```
settings_development.py
```
- configuration used for development, e.g.
```
DEBUG = True
```
.
```
settings_production.py
```
- configuration used for production, e.g.
```
SERVER_EMAIL
```
.
I tie these all together with a
```
settings.py
```
file that firstly imports
```
settings_local.py
```
, and then one of the other two.  It decides which to load by two settings inside
```
settings_local.py
```
-
```
DEVELOPMENT_HOSTS
```
and
```
PRODUCTION_HOSTS
```
.
```
settings.py
```
calls
```
platform.node()
```
to find the hostname of the machine it is running on, and then looks for that hostname in the lists, and loads the second settings file depending on which list it finds the hostname in.
That way, the only thing you really need to worry about is keeping the
```
settings_local.py
```
file up to date with the host-specific configuration, and everything else is handled automatically.
Check out an example
here
.