The scale-Out' computing architecture enables organizations to improve application performance and scalability on an incremental, as-needed basis by adding multiple replicated database servers on low-cost commodity hardware. In contrast, the Scale-Up approach requires organizations to make a large up-front investment in more expensive and complex server hardware and database licenses in order to add capacity.

Open source databases such as MySQL offer server replication and high availability features that allow high-traffic sites to horizontally 'scale out' applications, using multiple commodity machines to form one logical database, instead of 'scaling up', starting over with more expensive and complex hardware and database technology.

Businesses often fall into a few common traps when they first design their systems, only to run into performance issues once the explosive growth hits. The database experts at MySQL AB have used their real-world experiences to publish a “Do’s & Don’ts” article on the “Top 5 Common Scale-Out Pitfalls to Avoid”:

1. Don't Think Synchronously: large scale-out design should introduce asynchronous communication, parallelization, and strategies to deal with approximate or slightly outdated data.

2. Don't Think Vertically: plan for horizontal scale-out, almost from the start. If a business is already planning in the direction of distributed, asynchronous systems, it will make it easier to add more capacity later on.

3. Don't Mix Transactions with Business Intelligence: separate data onto different databases and/or servers to improve performance for both the transactional application and analytic operations.

4. Avoid Mixing Hot (frequently-changed) and Cold (more static) Data: since database writes are more difficult and expensive to scale, it is advisable to keep this type of data away from data that does not change that often.

5. Don't Forget the Power of Memory: a server's memory allocations should not be exhausted so that it becomes disk bound. An application's working set must be divided among the servers participating in a scale-out design so that data is always accessible in RAM.