So far we have examined the status quo, wherein various architectural alternatives of achieving improved elasticity and scalability using existing solutions are offered. But each of these methods has some significant drawbacks: shared-disk requires expensive hardware and software to achieve, shared-nothing requires partitioning the data that may not match the requirements of all applications, and NoSQL eliminates ACID and often, SQL. Clearly an alternative approach is needed – one that does not try to work around the shortcomings of the existing solutions.

At a high level, both scalability and elasticity help to improve availability and performance when demand is changing, especially when changes are unpredictable. If the data is not available, applications cannot run. If applications cannot run or run slowly, the company loses business. Therefore, it is important to be able to ensure that databases are kept online and operational.

Database Management Systems are at the heart of most applications and, as such, the ability to scale database systems elastically is important. This series of blog posts will examine the various methods used to accomplish database availability and elasticity, as well as introduce a new architectural option for database scaling.

As cloud and container-based environments become ubiquitous, organizations are increasingly moving away from high-performance static hardware to dynamically changing, virtual, commodity infrastructure. Systems need to expand and contract easily to meet an ever-changing demand – and that includes the database.

Database scaling is often implemented by clustering. Here’s a quick overview of the pros and cons of traditional architectural implementations: