Is Mongoose Bad?

So I’ve started learning MongoDB from their University and previously I had worked with it while following some tutorials from freeCodeCamp Youtube.

I initially thought that mongoose was the way to go when working with MongoDB but I stumbled on this article while going through MongoDS’s Resources.

It seems to me like they don’t really encourage using Mongoose and they make some valid points IMO that mongoose forces you more into a rigid design that might be better suited for SQL databases. Also setting up your own schema validation seems like a better idea in the long run when working with the database.

Any opinions? I’m still just getting started and don’t have that much experience with eighter so I might be missing some key aspects.

1 Like

“It is a skin to an Object Relational Mapper (ORM)”. An ORM is a language upon a another language. The main intention with ORM is to simplify, but sometimes it creates limitations.

If you are aware of that you do not learn MongoDB - you are learning Mongoose. And you are aware of that you add another layer to your application. I think it is OK.

I am an SQL guy using JSON within Postgresql (MongoDB within an SQL db sort of). All ORM on the SQL side are complete different languages, that looks simple in the beginning, but when you want to create something more sophisticated, you must still learn SQL.

My personal opinion is to avoid any interpreter. Like using Vanilla Javascript instead of jQuery.

Every language is a layer. JavaScript is written in C which is an abstraction of machine code which is an abstraction of the transistors and capacitors on the computer chips. Every layer of abstraction takes you a little further from the low level world of the computer chips but (in theory) makes it easier and faster to code. As a web developer, I don’t really care about the low level world. Heck, now I’m doing React with TypeScript, even more layers of abstraction.

As to Mongoose, I think they’re just trying to regain some of the control lost in NoSQL, trying to have the best of both worlds. That’s kind of how I think of TypeScript.

I’m not saying higher level abstractions are inherently better - it just depends on what you are doing.

1 Like

Right now I’m using mongoose, will try the MongoDB.js driver later on and try to compare them. For my purposes mongoose gets the job done quite fast… if I swing to the documentation page from time to time.

You are right. Using Mongoose puts you in a spot similar to that of an SQL database design, except with worse performance.

However, this “ridged design” can be helpful. The concept that MongoDB gives you complete freedom to define your schema, and have dynamic data is both its primary advantage, and a disadvantage.

If your data is super flexible and dynamic you end up with a lot more pain, in regards to not knowing how to optimize it, or really deal with it. Sure your database is flexible but your code isn’t.

There’s also the issue of data validation. MongoDB doesn’t care what your data looks like. Mongoose can enforce some rules to help protect it, by providing protections “at the code level”, rather than the DB level.

In the super long run it might be, but I’d only take this route if the idea of rebuilding Mongoose from scratch is the only option. Otherwise you’re re-inventing the wheel. Its also possible your app would outgrow MongoDB by the time you get around to finishing your own version of mongoose.

Depending on the requirements, the less optimal performance in the best cases might prevent MongoDB from being viable at all. For example, Discord started with MongoDB when they launched, but then had to transition to Cassandra (another NoSQL database, but aimed at large scales)


The key advantage of using something like MongoDB initially is the ability to iterate. Mongoose will enforce some rigidness to that iteration process, but it also applies it to an area where you usually always want rigidness. That area is the apps data. The last thing your code wants is data that is so dynamic it isn’t sure what it even is. Not only does it make it harder to write your entire application stack, it also makes it near impossible to debug.

Having “clean” organized data doesn’t mean you can’t also iterate quickly by simply making changes to the code to add new properties. This is in comparison to an SQL database that forces you to run a migration to update the tables and deal with any possible issues in that regard.

There is also the concept that understanding how to use MongoDB by itself is useful for later picking up mongoose to handle other cases Mongo doesn’t. As it isn’t an either or. You can use Mongoose for most things, then pull up an aggregate for situations where Mongoose wont cut it, or you need to optimize what you’re doing without getting “sandboxed” into just using what Mongoose provides.

The choice is ultimately up to you.

Good luck, keep learning, keep building :+1:

Thanks for the answers! Hope I’ll get the hang of it soon. Just stumbled on mongoose not helping me with a .slice("array.name, -1"). I’m probably not getting something right. So I’ve just rebuilt the object from my side, way less efficient but hey, at least it got the job done.

Thanks, gonna do that :sweat_smile:

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.