Should you use MongoDB as a drop-in SQL replacement?

27 Mar 2016

MongoDB is hot. It claims to be fast, better than these creepy SQL databases, fancy, and blah-blah-blah. But is it really a good option for your “typical” Rails application? Here by “typical” I mean an application with relations between models and CRUD and stuff.

Here are a few reasons Postgres (or well-configured MySQL) would have been better for that use case:

Enforced schema

Right, one of the “benefits” of Mongo is that you don’t have to maintain a structured schema… But what it actually means for you and your Rails app is, the schema and its enforcement are just shifted from the database to your application code.

Instead of having the DB handle the types, you coerce the types in your code.

Instead of having the DB handle some constraints, you try to handle them in your code.

Instead of having the DB change the schema (rename a column or so; these bad migrations!), you manually write scripts that iterate and change a document at a time. That involves getting literally all of your data into your program and doing something with it. Crazily inefficient. A DBMS can do it better.


Transactions are absolutely useful when doing an all-or-nothing update to multiple tables (like when debiting from one account and crediting to another). With Mongo, again, you have to manually implement code that mimics transactions.


A typical application has relations between pieces of data, and joins allow you to use a single query to, for example, get all users who posted more than 5 posts which got more than 10 comments. That particular example may sound far-fetched but there are a lot of similar legitimate queries a business might need.

Without joins, you would have to do all that matching in your own code, which really is a PITA, can get complicated quickly, and did I say slow?

Can you spot a pattern here? MongoDB just makes you do things, by hand and in an inefficient manner, that a proper DB would do for you.

“But MongoDB is webscale!”

“But SQL is complex”

It’s not really as complex as some people think. SQLBolt is a terrific and easy-to-follow resource if you want to fill that gap.

Also unlike MongoDB, you just use the SQL for aggregates and so on. You don’t need a separate “aggregation framework” for that.

“But what if I really need some of that schemaless stuff?”

Postgres has json type that allows you to store free-form data along with your records and still reap the benefits of an SQL database.

Think your friends would dig this article, too?


Want to level up your React skills?

Sign up below and I'll send you articles just like this about React straight to your inbox every week or so.

No spam, promise. I hate it as much as you do!

, enjoying the article? Now think of 3 friends who are interested in MongoDB, SQL and would be into it, and share the link with them! 👇