Why DynamoDB?

We use DynamoDB in our tutorial and suggested simple stack because it provides encryption-at-rest, scalability, doesn’t require a VPC, and is competitively priced even at scale. However, using a NoSQL database requires a somewhat different skill-set than is required for SQL databases.

NOTE: You can use any database you want with stacks generated by LazyStack!

We always start our application design with the development of a data model - often expressed as an Entity Relationship (“ER”) diagram.

Creating a SQL database schema from an ER model is usually pretty straight forward and if you have followed third-normal form (“3NF”) in your ER/Database specifications you end up with a database against which almost any query can be made reasonably efficient with appropriate indexing. In addition you can use foreign key constants to enforce data integrity in database operations. Also, transaction management is ubiquitous in commercial-grade SQL databases and that frees the application programmer from mundane programming required when an update goes wrong and needs to be undone. The downside of SQL databases is the cost and practical limits on their scalability. As application stacks have grown to accommodate Internet scale access, NoSQL databases have gained popularity because they perform better at scale for many of the use-cases typically found in Internet applications.

Creating a NoSQL database schema from an ER model is not straight forward. Your task is to de-normalize the model to group as much content as possible together for each necessary query your application may make. This allows the database to retrieve that information much more quickly and thus serve a larger number of concurrent database queries. This approach generally means that data is often duplicated, this in turn leads to the use of an “eventually correct” data retrieval approach. Most popular NoSQL databases still offer some level of transaction management but it isn’t assumed that this will be your default access method and in general this transaction management is both less robust and more expensive to perform than the same process in a SQL database. The biggest challenge of crafting a NoSQL database schema is capturing, ahead of time, all the queries your application will need. It is not easy to add an optimized query after the fact when using NoSQL schemas.

There are a very large number of SQL databases that have features that move them toward NoSQL performance levels - for instance Oracle's Materialized Views. There are also NoSQL databases that attempt to introduce SQL queries support - for instance Couchbase N1QL. We mention this just so we don’t leave you with the impression that the choice if database is really all that binary.

So, what should you pick? We believe that that depends on your skill-set, application needs and operational budget.

If you have a really complex ER model, have SQL skills, and you don’t expect your application will require massive scalability, then perhaps it is worth the extra VPC complexity and additional operating cost to use AWS RDS or stand up your own SQL server instance in your VPC. Be sure to carefully cost this out because it can get really expensive, really fast to stand-up a SQL server supporting encryption-at-rest on any PaaS.

On the other hand, if your ER model is simple, or you are comfortable using NoSQL, even with a complex ER model, then your least expensive and most scalable choice may be NoSQL and in particular DynamoDB if you want to stay in the AWS free-tier as long as possible.