As I see it, if we get enough traffic to be worried about scaling issues we'll deal with it then. Django isn't terribly designed and going in and hacking multi-db and sharding in should take less than a week from a competent developer.

Discussing this before starting a startup sort of feels like trying to figure out how to do salary for hundreds of employees before getting your first one.

I think it's worth discussing these things in depth. Choosing a web framework for your web company is a serious commitment, isn't it?

I agree it's worth discussing (especially if you're unsure about future malleability of the web framework to your needs), and I apologize if I was excessively curt.

We're running multiple databases, live, with the Django ORM. Confirming that it's not very hard.

Ah I knew there was the checkin, I wasn't aware it was currently useable. Thanks for the info, I will have to check it out.

The framework may not offer it as part of the framework, but there is nothing stopping you from doing it yourself. It's python, it's a database, what's the difficulty here? Django is not the type of framework where you run deep within it and you cannot break out - nothing stops you from doing anything you want to do.

Of course you're right. Then it's just a matter of assessing the cost of modifying Django vs. another framework.

What I mean is that you do not need to modify Django. You can just write a routine that duplicates whatever you are writing to the database manually. The Django process is easy to break out of from within your app.

Django has had low level, undocumented hooks for talking to multiple databases for ages (Malcolm talked about these at DjangoCon, the same conference that hosted Cal's excellent keynote). A very recent checkin makes those hooks easier to use: http://code.djangoproject.com/changeset/10026

Very cool. Thanks for this insight.