I’ve been working in the cloud industry for nearly the past decade, and can say, without a doubt, that Database as a Service is one of the most interesting and challenging domains I’ve encountered.
In 2005, I ran a software developers team that provided LAMP Software as a Service for enterprises; therefore, I became very familiar with the challenges of carrying out MySQL work for large scale demand. These challenges are further augmented when dealing with web applications that have exponential transaction rates and concurrent user growth.

Back then, we had a very lean R&D and were unable to afford the sacred Oracle license or keep an in-house DBA master. It was the typical garage startup. Alas, I still do not think that we have managed to overcome the obstacles I present here. It is exciting to see, however, that our small SaaS had the same challenges back then that every R&D organization is experiencing today, concerning an explosive growth in data. Over the past two years, I have become familiar with a few initiatives in the realm of Database as a Service, although I have had a difficult time finding appropriate market players. It was only recently that I learned about ScaleBase’s story.

Q: Why MySQL Scalability? A: Social Media.
We use MySQL because it is free, while LAMP was, and still is, the naïve option for a small R&D organization. Facebook was the same story; one person wrote a simple code and instantaneously received results using open source software. Today, this is understood. However, when these systems grow, so does the technology that is built in order to support the inevitable, accompanying exponential growth. Following a debate around MySQL’s ability to perform at scale, Facebook proudly published that MySQL wins, as it serves 60 million queries per second, and nearly 4 million row changes per second. My research has brought similar findings to light; namely that scaling out with MySQL generates efficient and cost effective linear scalability. Traditionally hosted database growth creates significant hurdles, regarding master-slave architecture scalability, performance, manageability become patch rotation, to name a few.
That being said, have you bought a larger machine for your expanding database? Could you afford it? Did you feel that it was just another expensive patch? If you have answered yes to these questions, the joyous success ordinarily coupled with business growth was most likely accompanied by an uninvited, major headache. The options of adding more slaves, separating between read and writes or even doing in-house Sharding are possible solutions to this problem, although Database as a Service (DaaS) is clearly the wisest decision. Taking a deeper look into ScaleBase, it seems like they have nailed this service, not for one, single database, but for multiple (of their customers’) accounts. Without changing anything, you can continue to use your MySQL database, as is. There is no need to migrate to a new database architecture or make any changes on the application level. If you stop for a split second and think about how cloud locks you in (data driven cloud lock-in) you will read again the previous sentences, and notice that it is more than a fun fact, it is an important value.
Scale-out Your Database: Sharding is the Challenge 
The evolution of DaaS (Database-as a Service) is naturally supported by the, theoretically, endless resources of the cloud, using multiple commodity “machines” offered by any cloud, and scaled-out elastically. To allow a database to scale-out, sessions and workloads needs to be distributed evenly across multiple database nodes, and for that to happen, the data needs to be distributed across database nodes. This distribution can be done by using an array of smaller database instances such as an assortment of commodity `cloud instances`. To achieve that you need to preform Sharding. You need to be able to analyze and plan the data distribution practice and then develop the logic so it is aligned with your service’s specific use case. In addition, your data distribution policy and logic must be operated, enforced and aligned correctly across the data policy coding within the application. Consider Sharding as an intelligent waste of time Again, the evolution of DaaS is only natural. Instead of your focusing your developers on your core application values you will have your most smart guys in the room working and maintaining the Sharding logic.
The complexity that Sharding implicates the ability to open your data to your ecosystem partners, not to mention that it adds additional level of complexity of running data analytics in order to learn more of this data. The solutions out there range from being able to control the nodes array, (like with AWS RDS – capacity planning and control is of an essence) all the way to the vendors such as ScaleBase, that accept liability for the entire stack’s performance and provides one MySQL table of data that can scale seamlessly. In either of these cases, it is apparent that `enabled cloud database` scalability is the natural progression. So you may want to let your DBA go … (just kidding, keep reading to see why they are important).
The DBA becomes a DBS (Database Strategist)
I have already described a few of the numerous challenges that are inherent in building and operating your own database scalability. Outside of the cloud, a DBA is a magician, traditionally performing tasks like resizing, installing, configuring and tuning. When it comes to scaling, however, a DBA always becomes an expensive bottleneck. For a DBA, the cloud (especially the public cloud) can be a complete savior. You are able to scale the number of necessary instances, volume and storage to host and support large scale relational databases. Therefore, sizing can take up a great deal of a DBA’s responsibility. Using ScaleBase for the private cloud, a DBA must be able to analyze the prerequisites for a system’s database and be able to forecast the necessary capacity in order to eliminate uncontrolled cost risks. As I have mentioned several times in the past, this is not an easy task since the cloud’s amazing flexibility continuously generates new risks. A DBA then moves up the cloud ladder, from being a talent administrator, to having a strategic role as an adviser and analyst.
Final Words
Running a database on the cloud is one of the considerable advantages of the cloud’s flexibility. It allows you to scale and change your database according to your actual business growth. Performance at scale, security and capacity are in the hands of your cloud operator, along with other various challenges. For that reason, a 30 people startup team is capable of delivering robust online services for millions of people, which brings me back to my main point (in case you missed it)…database scalability is cloud native.