I don't agree with that. I'd say don't worry about south if you're just starting out playing with django and willing to manually delete tables every now and then to get make sure your db matches your models.

As soon as you are doing something that anyone relies on and to save you endless effort you should use South, IMO. Even if it's a one-person project (I have a few of those) South saves you both a lot of time and aggravation.

Absolutely agree. Even something as simple as adding an optional field is just ./manage.py schemamigration --auto <appname> and you're done vs "ALTER TABLE blah blah blah...." on your local system, dev/staging, and then again on production in the right order, every time, manually. Can't imagine anyone wanting to go back to manual after using South.

This thread perfectly exemplifies the frustration laid out in my original post.

Welcome to development with open source technology. It takes time and effort to figure out the best practices. There is no magic bullet, sorry. That's not meant to be snarky it's just the way the process works.

And use Postgres as the database. If you use MySQL you will get sick of South telling you to use Postgres whenever a migration doesn´t go smoothly.

Definitely not good advice, regardless of what language or framework you're working with. If there's a solid migration tool available, it is definitely better to use it.

Aside from being a great habit to get into, South (or whatever other migration tool you want to use) will keep your database consistent and predictable to the framework. If you add or alter columns on your own, you run the risk of slight differences between what you've done and what the framework would've done left to its own devices. You may not have done anything wrong, but you don't want that inconsistency.

Migrations are going to be a core feature (quite similar to Ruby on Rails) from Django 1.7, and I personally find it more convenient. Eventually you will need to use migrations anyway.

I honestly find South to be the easiest and most efficient way to make model changes even on a solo project.

The biggest upside to it is that it fully documents all of your chances, and even allows rollbacks if necessary. Editing the database directly doesn't give you any kind of change log unless you do it manually, which is not really sustainable, even while working solo.