After reading http://highscalability.com/ http://highscalability.com/ for a while I've happily found myself using some tips from there from time to time. I've o

After reading http://highscalability.com/ http://highscalability.com/ for a while I've happily found myself using some tips from there from time to time. I've only used these methods a few times, I usually just push large database changing changes at night and try not to do anything that takes longer then 20 minutes. One way is to use two tables and have the application logic read from both and write to the new one. This can't always work easily but for tables that don't get a lot of joins its not that hard. Deploy the code, migrate the data into the new table and then drop the old table. I've used this once to update a user_profile table for a busy forum. Another way to mitigate downtime on table changes is to have lots of tables. I believe one of the larger Chinese social networks was reviewed on the HS blog and boasted that they found it easier not to have more then two columns on a table (pk and value). That's a little crazy imho, but I have see it working with smaller column groups. You use a lot of 1 to 1 relations and each column or logical group of columns gets it's own table with a foreign key to the main object. This way you can modify a column without restricting access to most of the object at the cost of more joins. I worked on a django project where we had a users table and any user information (there was a lot) was a different table. The data models were related to the user model and handled all the lookups. (User.profile, User.contact, User.reporting_prefrences, User.support_requests, etc.) I've never used mongodb or couch, but with a nosql you can just have the app logic take care of upgrading records on read. Run a script to upgrade everything. Drop the app logic.