RDBMS vs. DynamoDB and Serverless vs. not Serverless

Question

I have a little bit of a problem concerning the design of a planned application, especially database engine and Serverless/not serverless. The goal is a Web Application which talks via the Rest API to the database. The Rest API itself is really just CRUD operations, so for that the Serverless aproach (AWS Lambda) would fit pretty good in my opinion. For that, the probably most efficient database to choose would be DynamoDB (NoSQL).

I am familliar with RDBMS and have only little knowledge of NoSQL databases.

The Schema of the application is not yet finished and should be expandable at later points, because there could be new features to implement and so on. Because of this, i would rather use a RDBMS and not a NoSQL database, because they don't scale that well in terms of editing the schema at later points. (at least that's what i read the last couple of hours)

Choosing for example Amazon RDS MySQL database, would be much more expensive and i don't know how well they do with the Serverless aproach of the Rest API.

So i am standing at a point i really don't know what services to use here. Could i still use DynamoDB? The schema would propably be very relational.

Answer 1

DynamoDB doesn't have any concept of schema so the whole thing about editing is kind of unrelated (to DynamoDB). If by schema you mean objects with certain properties then it depends on the use case. If you are OK with having object in a table that don't share the same "schema" then it is extremely simple as that is allowed by default. On the other hand, if you need all the objects to share the same set of attributes and you are going to change them frequently then this is indeed not as easy and straight forward compared to RDS.

Next, if you have a relational schema - tables - and are planning to do some JOINs on them then DynamoDB is really not a good solution. DynamoDB is good for a specific type of use cases like storing sessions or something with similar (low) complexity. Writing more complex queries in DynamoDB can get very tedious and painful.

Considering the price. Well, I wouldn't really say that DynamoDB is that cheap. It seems like that at a first glance but if you dig deeper into it then you find that it is actually pretty expensive, mainly from the perspective of writes. You need to provision read and write capacity and more throughput you require the more costly it gets (you can go with auto-scaling for burst traffic but in case of consistent traffic, this will not help you that much). At larger scales, RDS (not Aurora) will cost only a fraction of what the DynamoDB will cost you (assuming that we are talking about use case which can be handled by RDS).

If you are worried about RDS integration with Lambda then the complexity is not that bigger compared to DynamoDB. There are some considerations that need to be taken such as the lambda execution time hard limit (which is currently 15 minutes) and RDS may be slower to respond (compared to DynamoDB), but if your query is taking that long then you are either doing something wrong or misusing those tools.

All in all, if you are comfortable with using RDS and don't need that millisecond latency provided by DynamoDB (or even microsecond latency if using DAX as well) then I would definitely go with RDS over DynamoDB in your case. Again, DynamoDB is not a general purpose solution to every data related problem and more often then not, I see it being heavily misused for stuff that can be easily handled by RDS.