One of the last things we had to upgrade in going from beta to full launch was our databases. Yes, there is more than one. We upgraded the chat database earlier this week and, when there were no problems, we upgraded the main databases yesterday (Saturday, 14 November). The main upgrade completed successfully, though it did take a few hours longer than anticipated. I've been asked to outline what we did and how it went, and I'm only happy to do that. Much of this is geekery, so if it doesn't interest you, that's cool. But for those who are interested in such things, let me remind you that transparency is one of our key goals.

During our initial development and beta, we made the decision to use separate databases for most systems at Model Insider. This decision was based on the theory that a modular approach was wiser. If a system needed work or broke, it was better to take just that system down rather than the whole site. As such, we created our backend databases and began the coding of the site. These databases were housed on shared hosting just like the site itself.

Shared hosting has both its good and bad points. It's good in that it's inexpensive. It's bad in that you're sharing infrastructure with many (sometimes hundreds if not thousands) of other people, any one of which can exhibit what is known as the "bad neighbor" effect. This is where our shared databases suffered the most. If someone in that shared pool decided they wanted to completely re-index their database, our performance suffered. If someone decided that they wanted to crash the database, we crashed, too. While our host's recycle process is quick in such cases, having it happen two or three times every day is never any fun.

The solution, then, is to get our own databases. This was our plan from day one, but we wanted to do it when we were closer to launch. One major reason, I'll be honest, is cost. It's not cheap. And since Model Insider only offers free accounts right now, I didn't want to open the wallet until we were prepared to move forward. That day is here, we made the decision, and as of yesterday, it's done.

So what happened yesterday? In short, we provisioned the new database on our own platform (it's called a "container"), backed-up the existing database and moved it to the new container. This is why the site had to be taken offline during the change: migrating a database while it's running is just asking for trouble. The challenge? The databases, put together, are BIG. Really big. And the move not only took time, but if there was a question as to the database's integrity, we had to err on the side of caution and simply start over. So it took longer than we had anticipated.

On the other hand, that's why we did it during the day, albeit on a Saturday. During the day there are senior support people on duty. Any problems can be immediately addressed. If we'd done it at 3am, at best we'd have to wake someone's poor rear out of bed. At worst, we'd simply have to wait until Sunday morning. Neither would be conducive to anything other than playing Torchlight while waiting (PS: speaking of geeking out, have you seen Torchlight yet? But I digress).

So... the bottom line is that we're now in our own database containers, we have complete control over them, we can do analysis for improvements without having to take other users at our host under consideration, and we have room to scale up as necessary. For the serious Internet geeks, our front-end is now on a scalable grid (cloud) and our backend is in a scalable container. I'm liking where we are at this point.

Questions?