Say No to NoSQL

Photo by Matt Bennett on Unsplash

If you have a high-load project or millions of users, then this article is not for you. This article is about small projects.

Also, suppose you are thinking about potentially millions of users that are not at all on the horizon. In that case, it also makes sense to think about the optimal choice of database for rapid development. In this case, it is more important to build the POC faster than to be ready for future workloads.

I understand the desire to bring as many new technologies into the project as possible. This approach works well for pet projects, but in real life generates a lot of extra bugs and significantly complicates the support and development of the system.

Consistency

Relational databases take the massive headache out of maintaining data consistency.

1. Data schema. You can always be sure that all data in the database matches the schema. No unexpected null fields, no stale data whose schema no one is sure about anymore.
2. ACID transactions allow you to always keep data in a predictable form. No intermediate states, when only a portion of the changes has been saved. No need to produce task schedulers and idempotent processing for the sake of it. It is enough just to wrap several operations in one transaction.
3. Foreign keys protect the integrity of the data and do not allow to leave abandoned data related to already deleted entities.

Indexes

Not all NoSQL databases allow you to build secondary indexes, and even fewer of them allow you to create unique secondary indexes.

It’s so nice when for the uniqueness of user emails, it’s enough just to create one index instead of inventing a sequence of complex operations.

Concurrency

Concurrency is a difficult topic and there is always room for mistakes.

If you need to implement a booking module or a simple payment system, then there is nothing more straightforward than taking a pessimistic lock on rows in the database. The readability of the code is noticeably increased, and the number of bugs is minimized.

Deploy

Finally, if the project is not hosted in clouds, then deploying and supporting a NoSQL solution may be a challenge for your DevOps. A split-brain may occur, file descriptors may run out, special tuning of the JVM may be required. It is not obvious what falls to expect from each particular database.

At the same time, any DevOps has an experience with relational databases.

Conclusion

All these problems are solvable, but it makes no sense to spend time on this at the start.

You will still have time to suffer from the collocation of data connected by a many-to-many relationship. But it is worth doing this when there is already confidence that an idea works, and significant user growth is coming.