I'm trying to understand what types of models that I have traditionally persisted relationally would translate well to some kind of NoSQL database. Suppose I have a model with the following relationships:

Product  1-----0..N  Order
Customer 1-----0..N  Order

And suppose I need to frequently query things like All Orders, All Products, All Customers, All Orders for Given Customer, All Orders for Given Product. My feeling is that this kind of model would not denormalize cleanly - If I had Product and Customer documents with embedded Orders, both documents would have duplicate orders.

So I think I'd need separate documents for all three entities. Does a characteristic like this typically indicate that a document database is not well suited for a given model? Generally speaking, would a document database perform as well as a relational database in this kind of situation?

I know very little about graph databases, but I understand that a graph database handles relationships more performantly than a document database - would a graph database be suited for this kind of model?

  • You have this tagged as 'mongoDB' and say in the question 'some kind of NoSQL database'. Mongo is a json / document based NoSQL database, but certainly not the only type (there are some significant differences between NoSQL databases). Are you going with mongodb? or is that still open (if so, would it be appropriate to remove that tag?)
    – user40980
    Oct 18, 2013 at 14:53
  • @MichaelT, MongoDB is mainly the document database that I have been looking at, so I thought I'd add the tag. But I'm open to other document databases if they would work better than MongoDB for this type of model. Feel free to remove the tag if it isn't appropriate.
    – Eric
    Oct 18, 2013 at 14:56
  • The confusion I have is that you mention Mongo, but then ask about graph databases. Mongo isn't seen as part of the graph family of NoSQL (see wikipedia NoSQL) - 'Mongo' is in the 'document store' family while 'Neo4j' is a 'graph' family db. The other consideration is that if you are talking about relations, then a relational database tends to be what you want (especially when you want enforced referential integrity - often desired for customer/order and product/order relationships).
    – user40980
    Oct 18, 2013 at 15:03
  • 1
    You may wish to look at programmers.stackexchange.com/questions/139108/… and programmers.stackexchange.com/questions/210482/… - that go into similar cases.
    – user40980
    Oct 18, 2013 at 15:06
  • @MichaelT, sorry for the confusion. I understand that Mongo isn't part of the graph family, so my question was mean to convey something like "Would Mongo or some other document db work for this? If not, would a graph database work for this?" I'll go ahead and remove the tag.
    – Eric
    Oct 18, 2013 at 15:08

1 Answer 1


In my opinion a document database would not be right for this. I have limited experience, though.

My experience: 15 years of SQL Server, 2 years of Postgres, only 2 projects with MongoDB.

After my years with relational databases I might be biased. But I have really tried to embrace the document concept. It is really great when you have documents, i.e. items that you want to update atomically.

You are describing relations. Relations belong in a relational database. There might be some more evolved document databases which are better for relational data. But they really are built for other uses.

After building some spikes with MongoDB, I built a Node project for relaying data between several external APIs and our own API. The server has been running for a couple of years and handles a couple of hundred thousand imports a year.

MongoDB seemed to be a great fit for this. But as soon as I added user and access control I started to long after a relational db again.

Document databases encourage you to throw everything at it. I challenge I encountered was version handling between different shaped json objects in the same collection (table). I ended up using JSON schema to validate everything going into the collections. This took away some of the freedom I gained by using MongoDB in the first place.

If I'd build that project again I'd do it with Postgres.

Two years ago I started a new project (Node server, React Native app). I started out with MongoDB, but the exact same thing bit me again. As soon as you start to handle users, ACL and critical relations you'll grow out of MongoDB. I switched to Postgres and the DB now consists of approx 100 normalized tables.

Postgres has a JSON field type which more than well makes up for what I missed from MongoDB.

Summary: Querying for data in MongoDB is no problem. You'll find everything you need in a snap. Indexing capabilities are great as well.

Keeping your relational data secure will be a challenge in MongoDB. ACID is the way to go imho.

If I'd grow out of the JSON field type in Postgres I could see myself using MongoDB for some storage, but the main db would definitely be relational.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.