Which database makes sense?
Choosing database for your next project
Which database is the right choice for my use case? This is very common question that’s brought up for System Design interviews as well as while actually building systems. The decision depends on lot of factors, let’s discuss a very high level view.
Decision Flowchart
Let me take a reference from my O’Reilly book “System Design on AWS” Chapter 3. Figure 1 shows a flow chart on how can you navigate through the choice of database over multiple options available in the market.
Figure 1 Decision Flowchart for Database Choice
The question that comes to your mind, can I follow this flowchart blindly to answer database choice questions? The answer is NO. In Software Architecture and design decisions, there are always trade-offs with any direction you go with. So saying, a particular database is perfect is wrong. In addition to the above flowchart, database choice should be combination of below factors:
Business Requirements
The most important decision criteria is that the database choice should meet the requirements. All other things comes later.
You can start by looking at data access patterns. The databases such as DynamoDB only makes sense if you know the access patterns. If there so many joins required, and you don’t what kind of queries will be there, relational database is better choice. This can very much happen for a new project or a startup; relational database is good choice to start with.
Don’t forget to checkout the “System Design on AWS” book for detailed dive deep on relational, non-relational databases and how best to use them.
Previous Expertise
If you already have expertise with some technology then you know how to use it in the best way possible. If something meets the requirements and you also have previous working experience, nothing beats this combination.
In case you’re new to databases or your use case is totally new, try to stick with battle-tested software. If a lot of people have used something at scale already, you’ll get ton of support from community.
Cost
You should be able to afford something to use it. Cost is important consideration, this is mostly applicable to managed offerings. When it comes to cost, I recommend to look at total cost of operations and not just the monthly bill paid to the provider.
See,
How much time you’re saving in launching your product by leveraging managed offering. This is also applicable to other solutions as well and not just databases.
How much operational burden it takes off from your plate.
With this, let’s conclude the discussion.
Conclusion
Always consider trade-offs for any decision you make, what are the pros and cons for any choice being made. Also, there is thin line between database features these days. There are a lot of managed relational database offerings with horizontal scaling support so you don’t have to implement this in-house. There are a lot of non-relational database offerings with transactional support.
I’ll recommend to choose non-relational only if you know you need it. Else stick to relational databases, they solves most of the requirements. Happy Building!
Check out the YouTube video for the discussion with the community -