What is our primary use case?
When the company started, MongoDB was our primary database.
It offers great flexibility where developers can define any key and assign a value to it. This means that there is very little that one has to plan in terms of designing the schema upfront, so developers enjoy a lot of flexibility. Now that we have more use cases for which NoSQL is not suitable, we are trying to move those workloads out of MongoDB.
What is most valuable?
MongoDB is extremely developer-friendly because when you are starting, there is very little time needed upfront in terms of planning. Whenever a developer wants to build a certain feature, they simply define a key and a value and that's it.
It is very easy to create an index on a field that you want to have searchable.
All of the documents are stored in JSON format, which gives developers a lot of flexibility.
What needs improvement?
MongoDB should not be used for reporting, analytics, or number-crunching tasks.
The pricing should be improved because the whole design is around replication of data, so in terms of storage costs, in the long run, it will be expensive. The amount of storage grows very quickly when compared to other databases that store data in normalized form. If there were a way that some data could be partitioned or moved into cold storage then it would be very good.
For how long have I used the solution?
We have been using MongoDB for about four and a half years.
What do I think about the stability of the solution?
There are bugs in the system but they are not very significant. We have found a workaround for each of those bugs and we have been running the full-scale production cluster for more than four and a half years. As we haven't had any issues, I would say that it is pretty stable.
This solution is used constantly by both us and our customers, every second of every day.
We are not looking at increasing our usage. Rather, we will be moving some of our workloads off of MongoDB. Ultimately, usage will be at a standstill or perhaps even reduced.
What do I think about the scalability of the solution?
This is a scalable solution. We have close to 100 developers who use it. In addition, our entire business makes use of MongoDB. Everything the customer does makes use of this solution, so I would say that we have at least 100,000 users.
How are customer service and technical support?
Because we are using the Community Edition, we don't have any support whatsoever.
We did interact with them for MongoDB Atlas, and we are still in contact with them to see if we can take something into production a couple of quarters from now.
Which solution did I use previously and why did I switch?
We did not use another NoSQL database solution prior to MongoDB.
How was the initial setup?
When we installed MongoDB the initial setup was complex. However, now with Atlas, it is very easy. It took us less than a week to deploy and now, with Atlas, there are a lot of things that you don't need to know that was required four years ago.
What about the implementation team?
I did the original cluster deployment on my own.
What's my experience with pricing, setup cost, and licensing?
We are using the Community Edition of MongoDB. However, we would be happy if the pricing for the full version were more competitive.
Which other solutions did I evaluate?
We use a lot of different database products and the choice depends on the use case.
With respect to NoSQL, we did not evaluate other vendors because when we implemented this solution four and a half years ago, it was the only scalable NoSQL database. This made it a rather obvious choice for us at the time.
What other advice do I have?
The features that I have looked for are in this solution and we are using an older version. The current cloud-offering, MongoDB Atlas, has even more features. It would be a natural fit for us, but it will not be easy to move because we have a lot of dependencies. We have to update drivers, isolate collections, and take care of other issues before we can switch.
My advice for anybody who is implementing this solution, or any other database, is to take care to plan your indexes because it is extremely important. Spending some time designing the document structure in the initial phase will certainly help you in the long run.
I would also suggest that in terms of sharding, try to think about it as early as possible so that when you are ready to scale, it will certainly help to reduce the workload.
Do not rely on MongoDB for any of the analytics use cases. Aggregation works well but do not use it for your reporting or analytics or number crunching-related tasks.
I would rate this solution a nine out of ten.
Which deployment model are you using for this solution?
Which version of this solution are you currently using?
3.0 Community Edition