Table of Contents for

Seven Databases in Seven Weeks, 2nd Edition

Wrap-Up

This chapter has been quite a ride! We explored not just the very interesting and powerful DynamoDB but also a broad swathe of AWS offerings, and we built a pretty darned scalable data pipeline for use in a far-away datacenter. DynamoDB presents us not just with a relatively ops-free experience but always with a data model that sits in a nice middle point between the granularity of SQL and the minimalism of most NoSQL data models.

DynamoDB’s Strengths

The strengths of DynamoDB have been on display throughout this chapter. It enables you to skip all the installation and setup steps and get started building immediately. And if you build something small, there are few intrinsic limits to how big it can get (if, of course, you have the budget for it). DynamoDB can be tricky in places, especially when it comes to things like capacity provisioning, planning for indexes, and coming up with a data model that enables you to take advantage of DynamoDB’s performance and scalability. But getting past the tricky parts unlocks a lot of possibilities.

Although DynamoDB requires you to give up some of the querying power of relational databases, its data and querying models provide some powerful constructs, such as indexes and range queries, that you won’t find in a lot of NoSQL databases. And if you run into barriers, such as the inability to write SQL-style queries for tables, you may be able to use an external service to fill in the gaps, as we did on Day 3. Beyond all of this, DynamoDB’s feature set continues to expand, as does the constellation of services surrounding DynamoDB in the AWS ecosystem.

DynamoDB’s Weaknesses

The drawbacks presented by DynamoDB are directly reminiscent of other NoSQL databases. Despite some interesting querying and modeling constructs, you’re probably better off using Postgres or another relational database unless you know for sure that you’re dealing with a DynamoDB-shaped problem (or maybe an HBase-shaped problem, or Mongo, and so on). Even if you have a use case that truly calls for a big NoSQL database, you may have trouble getting your data model to mesh well with DynamoDB’s partitioning system. And as always, there’s the cost. Any database you use is going to cost money somehow, but DynamoDB and others don’t always make financial sense. There may be times when it makes sense to run databases yourself, maybe on your own hardware and maybe in the cloud. Caveat emptor.

Parting Thoughts

Cloud databases aren’t everyone’s cup of tea. They require a lot of trust—trust in massive systems whose internals you can’t see and trust in the future economic prospects of cloud providers themselves. These and other drawbacks are real, but there are some major upsides, as we hope to have shown in this chapter. We urge anybody with a strong interest in databases to give them a try. Even if you don’t ever have a use case that requires a database like DynamoDB, we think that they’re greatly empowering for developers and just downright fun. They turn your humble little laptop into a very powerful orchestration platform.

DynamoDB is a good place to start but we focused on it here mostly due to its influence and market share. There are many other options. If you want a DynamoDB-style experience with a SQL favor, have a look at Google’s BigQuery or Amazon’s Redshift. For globally distributed databases, try Google Cloud Spanner, CockroachDB, or FaunaDB. We reckon that the database landscape is starting to lean strongly in the direction of the cloud and the ops-free lifestyle. The next edition of this book may even feature several cloud databases.