Why Your Startup Should Be Using a Database as a Service


When you're a startup, the most precious thing to you is time so why would you burn that time up administering a database in the cloud? In this article for the Compose Write Stuff program, Almog Koren talks about his experience doing that and how much better working with a Database-as-a-Service has been.

The Experience

A couple years ago we went working with IaaS (Infrastructure-as-a-Service) to PaaS (Platform-as-a-Service) and most startups realized the advantage of doing so, especially, in the early stages. Services like Heroku, AWS Beanstalk, Google Apps Engine and AppFog were the way to go. Now of course, this wasn't for everyone but the value was clear when choosing a PaaS. But when it came to our database this was not the case. Yes, you could use Heroku’s built in database. It’s managed but it’s really not a full "database as a service" and today, in most cases, startups are not using a Database-as-a-Service (DBaaS) but rolling out their own machines. I know this, because this is what we did in our own startup.

Scoreoid was my first startup, a gaming backend as service. I first developed our initial product using CakePHP and MySql which was great for a simple, minimal viable product. The issue was that Scoreoid grew too fast. This was great and how I knew I was doing something right. To give you the numbers, at the time when I first started out, I hit 1,500 registered game developers and 1,000 active games, mostly in mobile. All this was within two months. This might seem like small numbers, but was not back then. At the time, very few startups were able to get such great community support from game developers.

Within 3 months we started to run into major issues with MySql reads and writes, mostly as the code was not structured correctly. I was able to hold it together enough to bring in a co-founder and we went to work rebuilding everything in Ruby on Rails and MongoDB from the ground up.

We chose Rails as we had very little time and it seemed like a clear choice. Scoreoid was still growing at a rapid pace. This is where we made our biggest mistake. We decided to go with Microsoft Azure and to manage everything on our end. Azure was great but managing everything was not. We rolled out our own VM machines on Microsoft Azure, installed MongoDB, and ran our own cluster – one primary and two secondaries.

And as Scoreoid was growing in such a rapid peak; over the next 6 to 12 months we hit over 3,500 registered game developers, 3,000 active games and millions of players. Not to mention we had a number of the top Android games using our system. That mean traffic constantly going up.

The Crunch

Within weeks though we found ourselves dealing with constant database maintenance instead of developing our core platform. Not to mention we had to learn everything the hard way as there was no Mongo expert on our team and when you're starting off as a startup you can’t hire every expert. You have to move fast and get things done.

We ran into a number of issues like really getting an understanding how Mongo embeds work when you have lots of reads and writes but while that is more related to the code our biggest learning points was the infrastructure itself. We ran into issues were Azure would auto restart servers and trying to understand why this was happening wasn't so simple, especially when our secondaries would not kick in. Backups were also not backing up properly and everything from a simple upgrade wasn't so simple and took hours, which was simply time was wasted. Scaling at the database level also turned into an issue for us to be concerned about, consuming more of our time.

The Solution

What is a Database as a Service (DBaaS)?

"Database-as-a-Service (DBaaS) is a cloud computing service model that provides users with some form of access to a database without the need for setting up physical hardware, installing software or configuring for performance. All of the administrative tasks and maintenance are taken care of by the service provider so that all the user or application owner needs to do is use the database…" – Cory Janssen, Techopedia.com

This is important – "All of the administrative tasks and maintenance are taken care of by the service provider" – and this is what we learned the hard way at Scoreoid. During one of our peaks, as expected, we went down and the biggest learning point, that wow moment we had, was “we should have gone with a database as a service”.

It was clear why and the cost benefit becomes very clear when you're spending a week or more doing database “stuff” instead of working on your core platform. When it came to my next startup, thats exactly what we did.


If I were to sum it up in 8 clear and short points what I have learned the hard way, it would be:

I personally believe in choosing the right tool for the job or the right tech for the job. That’s very clear on my site. I’m sure there are cases where you would want to roll out your own machine and manage everything yourself, but always think twice about it. Working both with clients and my own projects using a database as a service has been amazing. Stay focused and work on your product and getting users – nothing else matters.

Almog Koren is a well experienced developer and owner of [Almog Design](http://almogdesign.net/) a rapidly excelling development studio proficient in a wide range of development solutions. Almog specializes in JavaScript and MeteorJS. and loves building engaging software helping companies large and small achieve their goals.

Conquer the Data Layer

Spend your time developing apps, not managing databases.