So you are starting the work on a brand new web application. You're picking up tools for the development, and one of them is a database (or, better said, a database management system - DBMS). You already know all the differences between SQL-based systems and MongoDb (there is plenty of information about this, so I won't duplicate it in this article).
But despite of this knowledge, you are still in doubt what kind of DBMS to choose (and there's nothing strange to this: it is a damn important decision!). If you've ever experienced this feeling, like this article right now and share it with friends!
However, this is much simpler than it may seem to be, at least in theory. I'll give you a straightforward rule about choosing a DBMS:
- if you application works with unstructured data, then choosing NoSQL would be a no-brainer (here I don't necessarily mean MongoDb, since depending on your needs, other type of NoSQL databases may fit your app better);
- otherwise, if the data of your application has a predefined structure, then SQL would be a good choice.
That sounds easy, doesn't it?
Most of web applications work with structured data (arguably). But before executing that CREATE DATABASE ... command for your new web app, it may make sense to consider a couple of factors.
First of all, initial maintenance costs of SQL-based systems are higher than of MongoDb (yes, from here I'm focusing on MongoDb again).
What do I mean by that? The thing is that due to the fixed data structure of SQL databases you will have to deal with database migrations. This means adding an entire step to your CI/CD flow. And this step is not fool-proof at all: remember that your app will eventually work with production data.
On the other hand, however, SQL databases (if used correctly, of course) will definitely make your data more stable, e.g. they will eventually help to reduce the number of bugs.
This means that the SQL vs MongoDb stuff is a classic stability-flexibility tradeoff.
At this point I may suppose that you probably expected a more exact advice when you read the title of this article. Giving advices is easy, that's why I won't do that :)
Instead, I can tell you about my own approach of selecting a DBMS.
In most cases (if not always) I work with web apps of structured data, I have mentioned something like that above. However, I often choose MongoDb for such apps, and not only because of its greater flexibility. The thing is that remote MongoDb storage services are generally more affordable than SQL, which is especially beneficial for toy projects and startups.
But ultimately I don't like asking the question: "Which DBMS should I marry my app with?".
Instead, I ask: "What if I choose wrong DBMS now, and how can I fix this mistake in the future?" (remember that humans are bad in predicting the future?).
So, to mitigate this risk, there are a couple of good ORMs we can apply, for example, Prisma. If at some point you decide to switch from SQL to MongoDb or vice versa, Prisma will help you to reduce costs of such transition.
And this is basically it what I think about the SQL vs MongoDb problem. Did I miss something? Write in comments! And don't forget to follow me so you don't miss out future articles!
Don't stop coding, don't stop growing!
Top comments (0)