MongoDB alternatives and competitors

Our primary use case of this solution was for working on PNRs and user journey plans for an airline. Things such as check-in times, airport arrival time, boarding times, etc. We stored all that data in Cassandra. I currently work as a chief technology officer.

The solution provided us with more than 100K PNRs a second and because the company was international there was a heavy data write, and at the same time a heavy data read. Cassandra helped us a lot, specifically to heavy write the data which was helpful and an amazing solution for us. 

I think the time series data was one of the best features along with auto publishing. For logging purposes, for example, you can say that after 30 days you won't need the data anymore and it goes. It was a great fit for our requirements. The good thing is that every cluster, every node in the cluster synchronizes the data in real time. That is something amazing that we loved.

One of the issues with the solution is that you cannot drop write like you're able to in MongoDB and MySQL, where you can join tables. Cassandra doesn't have joins between tables so you need other tools for that. You need to read all the data and put in memory and then add the joins. That is the area where I think they need improvement. Secondly, for example, when setting up your cursor, you have to be very sure about the read mechanism, because if you're not following the read mechanism and mistakenly build a key that is no longer unique then you start overriding data. There are a lot of improvements they could make including on the OS.

The stability is good although sometimes the solution slows down. I liked it and it's good for big data. 

The solution is scalable. If you need more nodes in your cluster, you can simply turn on a new node and it will automatically start synchronizing data. In real time, it will start sinking the data with that node. And that is a boost, that's the best one. The entire company was using the solution. 

Because we used a vendor, they supported us on technical issues and were very good. I do think they needed to improve their documentation. 

I have also previously used MongoDB which, from a technology perspective, has a collection base while Cassandra keeps data in the tables. It's a major difference. Every platform has its pros and cons. Cassandra does not provide an adopter kind of scenario. You need to use third parties to manage the relations. These are the differences and similarities but Cassandra does have a table structure which MongoDB does not have.

The vendor helped us with implementation. We had a team of around 25 working on deployment. Deployment was in multiple regions so it would definitely take a few hours, but let's say a three node cluster can be implemented in a couple of hours. It's a matter of understanding the architectural aspects. Once you have that you can decide on configuration.  

This was for an enterprise company and they are expensive. Cassandra has a heavy pricing mechanism because it's a yearly license. I'm pretty sure we were paying something around $50,000 annually at that time. 

I would suggest not over-complicating things. If you really need to have heavy write and you are okay with building keys by yourself, then go with Cassandra. If not, then the culture base is there, MongoDB is there. And MongoDB is the best one. If you are not enterprise, then don't kill yourself. Once I started working on Cassandra, the biggest lesson for me was needing to build. I need keys to retrieve data. If my key and the primary key is not well settled or well configured, then it is very tough for me to read data. 

I would rate this solution a seven out of 10. 

We are solution providers and we are vendors. We provide products to our clients.

I am working on Couchbase and Elasticsearch together. We use Couchbase as a family data engine for immigration assistance. We use Elasticsearch to replicate the data in realtime from Couchbase, and then we use the search functionality via Elasticsearch.

We are building a property listing system and when it was created we stored all of the data in Couchbase in realtime. We scrape from different sources and select the data from the user agents, and the property agent as well, and then store it. There is a retrieval method built into Couchbase.

I have found the views to be very valuable.

When using Couchbase, I did not face any issues and I think it's quite straightforward. The documentation is clear for the tools, the query, and the indexing. These are easily understood.

I have not faced any difficulty when using Couchbase. It may be because I am a senior developer, so it might be a problem for a junior developer, but I cannot say anything about them.

The interface is good, the dashboard is good, and the analytics is very good. These features have helped us a lot.

Most of the time, the only issued that I have faced was when we upgraded the Couchbase version. It is very difficult to load the backup of the older version to the newer version.

The only problem with it, I mentioned, the loading data from a different version. For that, we use replication to solve the issue. This is the only bad issue we faced, otherwise it is perfect.

I have been using Couchbase for three years.

Currently, I am using version 6.0.

It's stable. I have not experienced any issues.

It's a scalable solution.

In our organization, we have two to three people using Couchbase, and another two to three developers are using Elastic Search.

Communication with the technical support team is rare because most of the time, our clients have not purchased the enterprise version. We solve the issues on our end to keep the project cost low. The project was not too extensive, so we never needed to contact support.

Previously, we were using MongoDB.

The initial setup was straightforward.

We have deployed this solution onto our own cloud. We installed the Agentpoint and deployed Couchbase onto the enterprise cloud here.

The deployment took a couple of months, and to draw the schema and design the other requirements took three to four months.

I will be using the enhanced version when we set it up for the customer.

We have a team in our organization to maintain this solution.

We evaluated other options as well, but we choose Couchbase for the immediate consistency with Elastic, and the real-time native replication plugin, which is fantastic!

I plan to be using the enhanced version.

I would definitely recommend this solution to anyone who is interested in using it.

The enterprise version is a more stable version. The indexing is very powerful and the N1QL is especially useful when you come from an SQL background. It will be very powerful.

This is why I would recommend Couchbase. To this point, I have never needed anything extra added to it.

I am very happy with this solution, and I would rate Couchbase a nine out of ten.