hin255 - Fotolia

When should a developer transition to DBaaS?

Managing and scaling from a DB to a DBaaS takes a significant effort for a developer. Find out to make those updates a little easier.

Database as a service (DBaaS) makes a lot of sense in today's low-overhead-focused developer world. It makes no sense to have to hire DBAs just to manage things like security updates, patches and optimization of your indexes. While some level of this still needs to take place, the "tipping point," so to say, would be when you realize that your core business isn't running databases and that you're spending more time on managing and scaling your database than on your core projects.

Migrating an existing database to a DBaaS can be complicated; you have to make sure the DBaaS supports the same features that you're already using (for example, how the indexes work, the query syntax, transactions, incrementing IDs, etc.). There are many levels of DBaaS that you can use, from fully managed NoSQL databases like DynamoDB or Google BigTable, to less-managed systems like Amazon RDS for MySQL or PostgreSQL. The key is to make sure you find something that is compatible, scalable and fault tolerant. Database queries will be more expensive if you're moving them off of your network, since there will be a longer network delay, so you need to make sure you're handling that.

The biggest mistake that I've made with DBaaS is to assume that I needed something that I never ended up using. For example, I started with using Amazon SimpleDB because I wanted to make sure our system would scale. The problem is that SimpleDB couldn't scale to the volume of Stories I needed to support, and scaled poorly for the simple metadata objects I needed to store. You don't always need all of your data in the same type of database. Now what I'm doing is storing the high-volume objects (Stories) in a NoSQL DB with a search system indexing them, and the lower-volume objects that contain metadata in MySQL with read-replicas. I also plan to switch over to Amazon Aurora at some point since it scales better than MySQL, but is fully compatible with it.

The single most important key to choosing a DBaaS is to make sure that you're picking out what you need and not too much more than what you need. Watch out for side effects, and don't assume that a cloud-based DBaaS will be faster than a local database. Make sure your application does some caching, and consider adding a cache layer on top of your database connections, not just querying the database every time you need to access data. Also don't assume you need one database to fit all of your data.

Popular DBaaS offerings

Amazon DynamoDB
Similar to MongoDB, this is a key-value store that does support secondary indexes. It's not nearly as powerful as MongoDB in terms of storage, but it's very simple to scale and has a lot of flexibility in terms of data it can store. It's also incredibly fast and you can provision the throughput you want to get.

Amazon S3
Some may not think of it as a database, but it really is. It is a very basic key-value store in that there are no secondary indexes. It does support versioning, though, which can be very powerful. It's not fast, but it can store massive documents, including full binary objects over 1 GB in size. It is useful for storing simple binary data like videos or documents.

Amazon RDS
Amazon offers many flavors of Relational Databases as a service, including MySQL and PostgreSQL. Both of these services offer simple open source platforms that are managed by Amazon.

Amazon Aurora
Realizing that many developers love to use open source databases like MySQL, Amazon found a way to make a MySQL-compatible database that can scale and support faster operations. Aurora is brand-new, but is faster and more scalable then MySQL, without losing any compatibility. You'll get that familiar feeling of MySQL, but with the power to scale to your business.

Amazon RedShift
Technically, this is a data warehouse. It supports some basic SQL queries, but is very slow and doesn't offer any customized indexes. You can store petabytes of information in it, but you'll have a much harder time working with it if you're trying to get any sort of real-time connections out of it.

Google BigQuery
This is Google’s version of a SQL database. It's write-only, which is pretty interesting because it tends to make you add a field for "versions." It also supports really complex types, including arrays, but lets you query out using simple SQL. It's relatively slow compared to traditional NoSQL databases, but faster than Redshift. It scales automatically for you and can handle a massive amount of data without you doing anything.

Oracle DBaaS
This is Oracle's database, hosted by Oracle. It's great if you need to use Oracle, but it's expensive. It's fast and fully managed, but it's from a legacy provider trying to catch up to the modern age. You'll still probably need an Oracle DBA to handle integrations and make sure your indexes are set up properly, but you won't need to manage hardware.

Now part of Google, Firebase made a lot of waves this year, being a fully integrated database specifically designed for integration in your mobile and Web applications. The neat part about Firebase is that it's designed to let you use it right from a client system, not requiring you to have a back end at all. It's fast, scalable and very powerful.

Next Steps

Pros and cons of DBaaS

Dig Deeper on Cloud application development