Why Your Startup Should Be Using a Database as a Service

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 wowmoment 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.

Takeaways

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

• More precious time: When not using a database as a service, you're spending unnecessary time on something that can be done by someone else. That's time that could be used to let you worry about your product.

• Explicit costs: Not only is time costly which is really important for a startup, but we ended up outsourcing to a system admin to help with updates, backups and maintenance. This cost makes no sense for a startup no matter the thinking behind it.

• Experts to help you: When we went down, we had to learn to do everything on our end which is great, but sometimes it’s better to have an expert you can talk with. At the end of the day service providers like Compose are experts. They know and understand databases. This is what they do. Having an option to ask for help goes a long way.

• Much easier to scale: When we hit our peak at Scoreoid we had to increase our machine size and start looking at scaling in a serious way. Now, using a database as a service on my new startup scaling is much easier. Literally a click of a button and an email to support.

• Long term growth: We always thought that as we grew the cost in using a database as a service would become too expensive. Looking back, this is nothing but a misconception. While the cost does grow we save more money by cutting down on maintenance, HR and our time and as mentioned earlier, we are able to scale much better.

• Less to worry about: At the end of the day, there is one thing less to worry about, which can go a long way for a startup.

• The experience: Using a database as a service now and looking back... Wow, everything is much easier with a database as a service. You have to really have to have used such a service to really understand it though.

• Everything is covered: Everything from indexing, auto backups, easy recovery, alerts, performance monitoring and much more.

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.