Selecting a database in a new project

Disclaimer: The article focuses on the choice of database, and although the context can be expanded to the choice of language, framework, etc., I propose to concentrate on only one aspect.

When developing an application, service, system, etc., one of the main questions arises: how should I store data (which database to choose). Due to the fact that most often you will get the answer “it depends”, I propose to consider several strategies that will work almost always.

Choose familiar technology

When developing, you should proceed from what your team, company, and yourself can (and can) work with. Often we want to try out new technology. As you know, the best place and time for this is a new project. So write a pet project and test it there. If we are talking about commercial development, then knowledge of the technology will speed you up and help you avoid running into pitfalls.

Follow company standards

Large companies often (almost always) have a certain scope of technologies “supported” by the company. In small companies, such standards may not be explicitly described. They look like “all our services use MySQL.”
On the one hand, it can limit you. On the other hand, the company has already accumulated a pool of “experts” in this technology. “Experts” can help both with advice and by providing templates for solving common problems. Very often we do not solve some fundamentally new problem, but simply adapt it to the subject area.

Does this always work?

I think so. At the initial stage of design, one must proceed from current conditions. Otherwise it will look like this: we are all Java developers, but we will write a new service in Erlang.

But I'm in the cloud!

Will this work if you use AWS, Azure, GCP, etc. with fashionable DBaaS? Yes, it will. DBaaS solves the problem of database deployment and, to some extent, solves the problem of support. But the problems of working with specific technologies remain. Additionally, DBaaS is typically more limited in terms of configuration flexibility.

But the standard solution definitely won’t suit me!

This could indeed be true. But the best option is to test your hypothesis. Implementation of two Proof of Concepts with a standard database and a highly specialized one for your tasks. First, you need to understand how much better your solution is than the standard one. Secondly, numbers will help you argue your position. And do not forget that in this case it is necessary to resolve issues of operation and support of the new database.

Conclusion

• Based on expertise

• Based on general practices (team/company)

• Standard solutions do not always work, but this brings new problems

• Flexibility and openness to new approaches are also important, even when choosing proven and familiar solutions

PS: After discussions on this post telegram channel I think it is necessary to leave a small addition.

The most complete selection algorithm is:

1. Understand the data model

2. Calculate the amount of data

3. Understand data access patterns (reading and writing)

4. Explore offers

5. Compare your needs with the capabilities of the Databases

6. Check availability of expertise

7. Select potential candidates and conduct comparative analysis

8. Leave room for future migrations

9. Perform load testing

10. Pin your choice

However, I would only use it if the standard solution definitely won’t work for you. The default strategy is to use the approach described in this article.