Mongodb-native over mongoose?

Jacob Samuel G. on March 03, 2018

Everyone uses mongoose! I do not like mongoose, all the abstractions that it implements have not been very useful when making complex transaction... [Read Full]
markdown guide

So my first reaction to your question was "huh, why would you not want to use Mongoose?" I am using Mongoose because it was recommended to me, and I never really looked into using MongoDB without it.

But then I looked at the MongoDB docs, and you are on to something! Compare the queries below:

Using Mongoose:

Book.find({ 'released_in_year': 2017 }, 'title author')

Using pure Mongo:{released_in_year:{'2017'}}, {title: true, author: true})

I'd say they're both pretty readable. What I think is the answer to "should I use Mongoose or not" really depends on the app you're building. For simpler apps you don't need the extra abstraction layer that Mongoose adds. For more complex apps with complicated querying, using Mongoose probably makes your life a bit easier.


It's true, it depends on the application.

Personally I have decided not to use mongoose in projects where 80% of its extra features will not be used (schema, virtuals, pupulate, hooks, etc.).

And although it is not "so" important, the native driver is faster! The only thing is that we must manually configure the connection pool, although it is not difficult.


Being MongoDB a database without real schemas and structures of the data you save in each document of each collection I always felt the schemas of mongoose is trying to use MongoDB as a SQL db, and if you are going to do that just use PostgreSQL, MySQL, etc.

That said, mongoose is far better than any ORM for PostgreSQL and MySQL on the Node.js world IMO.

goes against to the MVC

You may not need to use MVC if you don't like to follow it, it's not a rule you need to always follow 😉


Hello! The world is small, i know you from Platzi.
Your opinion gives me some peace of mind. I think that the mvc "sometimes" feels forced in javascript.


I actually stopped using MVC (also ORMs, also OOP) after a couple of years developing on Node.js.

My life got much easier since then and I never looked back.


I think it definitely varies from person to person which abstraction layer they want to insert at. Mongoose certainly is an abstraction and is probably not for everyone or every use case.


I've used Mongo in my node apps for at least 7 years, I've used Mongoose once in that time, and hated it (was chosen before I got onto the project) Otherwise I've either used mongojs or mongodb, much nicer experience. If you are using a schema-less db, why on earth do you want to bring in a schema? Maybe validation? But really, your validation should probably be somewhere before hitting the db/model, at either the api entry point or before it ever leaves the browser. So validation should be sharable between the client and server, not at the db level.


That's what I think about validation, and that's the main reason why I migrated to the native controller.


I promote Mongoose in my courses as a design tool. Abstraction is often used as a contract, and with a Mongoose schema I can create and enforce the contract for the interface into the database. The schema also helps me think about the structure of the data and its relationships.

If the app had a requirement for storing arbitrary objects I'd probably just use mongoDB without the Mongoose abstraction, but in my experience that sort of requirement is pretty rare.


MongoDB had native schema validation since 3.2 (2015) but who cares - everybody promotes Mongoose in their courses.


Mongodb was the first serious database I learned when I fell in love with web dev and node.

Unfortunately I am having the hardest time installing it on a Windows 7 machine I had to factory reset. Has anyone had experience with graphql? Is it better more more usable than Mongo?


GraphQL isn't a database as far as I remember. Just an abstraction layer on top of a database. No?


As far as I know graphQL is just a query language and not a database system. If you want to work with it, you still have to install a database. Someone correct me if I'm wrong ;)


My apologies I'm not looking for something that I don't need you install.

I was just wondering if anyone had experience with graphql and mongoose and Clips Blaine some differences.

Sorry about that

Hi Peter. As they mentioned before, graphql does not store data (it is not a database). It is a query language for APIS. In other words, it allows you to communicate with an api through queries like "SQL", that's all. It is more like a tool, that allows to work with an architecture different from the traditional REST APIs that work through endpoints and HTTP methods. I highly recommend reading the documentation, it is vastly fresh! :)

I have been working my way through YouTube conferences, docs and examples. Cannot wait for comprehension to give way to practicality


the first db I learned was mongo and now I’m looking at sql. I wonder what they’re good for....
This is coming from someone who wants to make tiny web apps that take open data and with hundreds of users in mind only


If you know well the concurrence of what you are going to build, it is a great advantage.

In my opinion, if your data manages "many to many" relationships you should use relational databases, even for "one to many". You can make complex relationships in mongodb, but you should make several calls to the database to populate the references, which translates into more code lines and more checks. If that does not concern you, then go for mongodb.
As an extra note, with mongoose you do not have to worry about references, since he handles them for you. It's one of his advantages!
I do not like mongoose, but I'm aware that it's very useful.

Mongodb, or any other noSQL, stands out in applications that handle very specific relationships.
Also, it is very useful for applications in constant change and evolution, it works great in methodologies that use the "minimum viable product", since it allows you to modify the flow of data easily, thanks to its flexible scheme.
Another thing that stands out from mongo is its native ability to scale horizontally.

All this is my opinion and experience. I currently use mongo because it works well with nodejs and it was the first thing I learned. However, I want to learn postgreSQL in the future, since a query language has its own benefits.


thanks for sharing your experience. I’ve used mongoose once (forgot about it) and mongo native driver since then. Ive been doing Postgres queries at work and I find that it’s much more semantic than mongo .find() etc but I can see how relationships between tables are very structured to begin with. I’ve yet to see how creating and updating a sql db differs; will have to report back on that one!


Isn't Mongoose like spoon feeding? I had a really bad experience with mongoose for a large data set.
If you're going large you should go with the Father.
@Jacob you spoke my words. Thanks for this post


Great discussion!
I am still using MongoDB naive driver for my applications, my seriously considering moving to mongoose.
The main reason is that security (JWT e.g.), modeling and verification (ObjectID e.g.) would be much easier and cleaner with mongoose.
Using mongoose bulit-in library, would allow you to reduce code from your project and let you focus on your core application.


Very true, sometimes we forget that productivity matters. With mongoose we are definitely more productive.


Why I should use mongoose when I am looking desperately to move to MongoDB in order to get rid of all kind of nonsense schemas.... only usefullness I find is that it can provide an abstraction layer to work with OOP applications in format of model...

BUT basically I will choose native Mongo to avoid break for schema... please coreect if there is any other usefulness Mongo can provide....


At the beginning I want to save time, so I learned mongoose. When I need to use aggregation/lookup or similar, I don't know how to it in mongoose or feel to be restricted.

Now I back to mongodb native. I get all, especially, freedom.


Panacea - There is none in coding.

Today you might not want or need mongoose, other times you might.

It’s a tool, just because you decided it isn’t the tool for your current job doesn’t mean it doesn’t belong in your toolbox.


You could create a joi schema as MW to validate your data and keep a reference of what kind of data you are saving.


In fact, I use joi, it is very good and allows for deeper validations, even sanitation and escaping.


I am a huge proponent of Mongoose. What are the scenarios where Mongoose doesn't work for you?


Hello Nick! I have been reading more about mongoose, I know it is quite useful and has everything covered. But that's what I do not like.

Sometimes I prefer to use other libraries (or create them) to perform specific jobs, such as validation or sanitization, for example.
In the end, term using few features of mongoose.

I guess it's a personal thing, but I want to know the opinion of other developers about this. I see that there are very few using the native driver, nor do I plan to go against the current :)

code of conduct - report abuse