Back

MongoDB Sucks (or does it not ?)

MD Rashid Hussain
MD Rashid Hussain
Dec-2022  -  6 minutes to read

MongoDB is an awesome solution, thanks to its document-oriented NoSQL features and capability of MapReduce calculation. The vision behind MongoDB was actually to keep a maximum number of functionalities possible and at the same time allowing horizontal scale for making the developer’s life far more convenient and easier. It is positioned between the high performance yet simple and uncomplicated key value store and the powerful yet inefficient relational database system.

No doubt, I love MongoDB due to its flexibility and ease of use. If you dont know, how your app is going to be in the future and no idea of data models to design, you can go with MongoDB and enjoy the flexibility. Just dump the json (as bson to be more specific) in the database and dont care about that shit again.

MongoDB may seem to be a cool database but you must make sure that it is the perfect database for you before making the final choice. You need to examine the advantages and also the disadvantages of the database. Nothing could be more disastrous than you building up your entire application on a specific database model but later on you learn that they just are not compatible with each other.

  • **Capable of Load Balancing & Sharding ** Sharding is a type of database partitioning that separates large databases into smaller, faster, more easily managed parts. These smaller parts are called data shards. The word shard means "a small part of a whole." Read more about sharding here. and here If you have loads of data or just in case, you wish to distribute your database’s traffic among diverse machines for balancing the load, MongoDB is supposed to be much more advantageous than any other traditional database. Sharding is supposed to be MongoDB’s distinctive approach meant specifically for fulfilling the needs of data growth. It utilizes horizontal scaling and lets you use multiple machines to support data growth.
  • Really Flexible (change-friendly design) MongoDB requires no data structures which seem to be unified across all objects that are in use. This feature makes MongoDB much easier and simpler to use than RDBMS. On the contrary, data consistency is really crucial at times and it is usually supposed to be a great thing, hence, it is recommended that you utilize unified data structure.
  • Super-Speed MongoDB is supposed to be extremely quick as all data is usually found at one single location. This holds well, only when the data being worked upon is in reality, a document. In case the data you are actually working on emulates relational model one single document could be retrieved after carrying out a number of independent queries and this would certainly make it much slower when compared to an RDBMS.

  • Logging service For loggers, you just need a place to dump all your logs and in this regard, mongoDB is quite a good database where you can store logs. In general, you can use it for any unrelated/secluded data
  • Loads of data involved
  • Analytics
  • Unstructed data where your data does not have a well defined structure, and you want to store.

I have been using mongoDB for the most part of my dev journey and had a very welcoming response from it and I am sure most of us as a javascript developers have similar experiences. But, when you go deep inside the inner workings, your data model/structure of your data, performance etc. things start to fall apart.

Below are some of the points, due to which I think MongoDb is not quite good for most of our needs.

  • More Memory MongoDB is known to consume more memory as it is known to store every document along with the key name. Just because joins and slow queries are not possible you seem to end up quite often, dealing with duplicate data.
  • Not good at maintaining relationships (Absence of Joins) Quite similar to a relational database, it is just not possible to have joins in MongoDB. If you ever require the actual functionality of joins, it is necessary to go about creating multiple queries which you would require to join manually very much in the code.
  • no support for transactions certain atomic operations are supported, at a single document level
  • Certain operations result in a full database lock (ex. write operations) leading to concurrency issues
  • Inconsistent (or eventually consistent) by design (lack of standardisation)
  • If all you need a document database MongoDB serves the purpose very well

This point of not able to maintain relationships between your data and not able to perform joins on your data is quite a big issue. In today's times, I can't imagine a medium to large application, which does not include any relation. In any application that involves uses user authentication, you need user table and something is always related to the user, being it user centric in the app.

Let's imagine a scenario where an app involves users. Users can comment on posts and each comment can have multiple reactions from any other user. Using mongodb in such a scenario, you have two options

// option 1 Involves subdocuments
import mongoose from 'mongoose';
 
interface IComment {
  body: string;
  reactions: string[];
}
 
interface IUser {
  username: string;
  password: string;
  comments: IComment[];
}
 
const userSchema = new mongoose.Schema<IUser>(
  {
    username: { type: String, required: true },
    password: { type: String, required: true },
    comments: [
      {
        body: String,
        reactions: [{ type: String }],
      },
    ],
  },
  { timestamps: true }
);
 
export const User = mongoose.model<IUser>('User', userSchema);
// option 2 involves imitating a RDBMS
import mongoose from 'mongoose';
 
interface IReaction {
  reaction: string;
}
 
const reactionSchema = new mongoose.Schema<IReaction>(
  { reaction: String },
  { timestamps: true }
);
 
export const Relation = mongoose.model<IReaction>('Relation', relationSchema);
 
interface IComment {
  body: string;
}
 
const commentSchema = new mongoose.Schema<IComment>(
  {
    body: String,
    reactions: {
      type: mongoose.Schema.Types.ObjectId,
      rel: 'Relation',
    },
  },
  { timestamps: true }
);
 
export const Comment = mongoose.model<IComment>('Comment', commentSchema);
 
interface IUser {
  username: string;
  password: string;
  comments: IComment[];
}
 
const userSchema = new mongoose.Schema(
  {
    username: { type: String, required: true },
    password: { type: String, required: true },
    comments: [
      {
        type: mongoose.Schema.Types.ObjectId,
        rel: 'Comment',
      },
    ],
  },
  { timestamps: true }
);
 
export const User = mongoose.model<IUser>('User', userSchema);

The second approach looks legit and sensible but it is seems like a crazy hack to imitate a RDBMS design and this certainly comes with some caveats due to inherent nature of how mongoDB is designed.

One of the most important lackings of mongodb is the inability to perform transactions like in RDBMS. If you handle sensitive data in your application involving financial and medical data, you cant afford data loss. RDBMS handles this using something called ACID properties, which are as far as i know, not baked into mongoDB.

But, despite all this, mongoDB has seen rapid growth and improvements in the recent past and has incorporated a lot of improvements.