Couchbase Server

Our main use case for Couchbase Enterprise  involves feature configuration management in the hospitality domain. Ours is a SaaS product, and we expose our product to multiple customers such as Marriott, IHG, and MGM, which are chains of hotels. We differentiate the features based on their subscription plans, such as one billion subscription plan from GMG versus a 500 million subscription plan from IHG. In this way, we use FCAM to identify and configure the features that specific chains are entitled to use, storing these configurations in separate documents in Couchbase for IHG, MGM, and Marriott.

We use Couchbase Enterprise  to store NoSQL data. We have a new feature called feature configuration management where we store each document in Couchbase for each chain, maintaining separate repository configurations for each.

Mostly we use Couchbase Enterprise for this use case only.

Couchbase Enterprise offers very fast retrieval of feature configurations, which is why we choose it over other NoSQL databases available. The downtime is very low, something I have observed over the past two and a half years, making it a notable feature.

I have never experienced any downtime with Couchbase Enterprise even with large volumes of data or complex queries. We have big customers such as Marriott who have around 10,000 to 20,000 features configured under their chain, and we have tried retrieving data multiple times, employing batch jobs and cron jobs without facing any latency.

Couchbase Enterprise positively impacts our organization because we have previously encountered issues with different NoSQL databases in the market such as Aerospike and MongoDB. Our use case involves a lot of transactional calls where latency must be minimal; hence we opted for Couchbase Enterprise to ensure API responses occur in less than 100 milliseconds, which has been very effective for our downstream and upstream components.

Since day one with Couchbase Enterprise, I have never exceeded the TPS configured for each API, with response times typically between 30 to 40 milliseconds.

The UI I am using is not very user-friendly. There are no dropdown options, and I have to manually enter the key and its value to retrieve any specific document, so adding some toggles or dropdowns would be an improvement.

The core product is good, and I only have a concern about the UI, so if they can improve that, it would be great.

I have been using Couchbase since two and a half years in our back end application.

Couchbase Enterprise has not shown any low latency in handling peak loads or high user traffic; its performance remains excellent. Couchbase Enterprise is very stable, and we evaluated various options such as MongoDB and Aerospike before concluding that Couchbase Enterprise was the best fit for our needs.

Couchbase Enterprise is very scalable, and we have a configuration such as KEDA to manage incoming traffic, allowing automatic increases in database instances based on user load, which is effective in handling peak traffic.

We have interacted with Couchbase Enterprise's customer support for troubleshooting issues, and my experience with them was positive; they were very helpful.

I would rate the customer support of Couchbase Enterprise a nine.

We previously used another NoSQL database that caused many issues, which led us to migrate to Couchbase Enterprise. After the migration, we have not faced any significant issues, and everything has been running smoothly.

Couchbase Enterprise's documentation and community support are useful for basic setup and common issues, although it may not cover all possible problems.

I did not personally handle the integration since I am part of the backend team, but from what I can observe, integrating Couchbase Enterprise was very simple. The libraries provided a lot of basic retrieve queries, allowing straightforward backend integration.

I do not have much insight into Couchbase Enterprise's pricing, setup cost, and licensing. My team typically manages that data, and from my perspective as a user, I just utilize it and deploy our APIs.

The learning curve for new users of Couchbase Enterprise is very easy. We have available documentation; when we did the integration, we documented everything so new team members can easily access these documents to help them understand Couchbase Enterprise.

Couchbase Enterprise is very secure in protecting our data because, in comparison to other NoSQL databases where we have lost data previously, we have not experienced any issues with Couchbase Enterprise.

I would advise others looking into using Couchbase Enterprise to consider it if they want a stable database with low latency and minimal downtime. I would rate this review an eight overall.

Basically we have clusters, Couchbase  clusters, databases, and that is how we use Couchbase  with XDCR. All the clusters are set up and then we use Couchbase. It is a complex application setup we use with Couchbase. We have replication and multi-node Couchbase setup.

The very useful feature of Couchbase is the online addition and deletion of nodes which we use because of XDCR replication. We use this very regularly.

Couchbase has an indexing part that is easy to build. We can create indexes in advance, before we have the data, and then we can stack in the data. This is something we use regularly.

The main issue we keep facing from the past couple of years, observing other teams using Couchbase, is that whenever there is an upgrade, we see many issues with compatibility or nodes not interconnecting after the upgrade. The upgrade part should be taken care of very carefully.

We contacted Couchbase support recently when we had a similar issue. They were helping, but it is a critical system and application we have set up. They need to rethink about their upgrade process and improve their validation part after the upgrade.

My team has contacted Couchbase support directly. I think they provide good support, but we prefer a proactive approach rather than reactive because this is not the first time we are facing issues after an upgrade. It has happened two or three times. We need to be very cautious during upgrades, and application teams get worried because of earlier experiences. We need to avoid these situations.

Our team has been using Couchbase for a while, but I started using it only in the last year.

We encounter compatibility issues with JDK and similar technologies whenever we perform upgrades. We had some issues recently.

We contacted Couchbase support recently when we had an issue. They were helpful, but since we have a critical system and application, they need to rethink their upgrade process and improve their validation after upgrades.

My team has contacted Couchbase support directly. They provide good support, but we prefer a proactive approach rather than reactive because this is not the first time we are facing issues after an upgrade. It has happened multiple times, requiring extra caution during upgrades, which causes worry among application teams due to previous experiences.

I worked with other document databases, MongoDB  database and Firestore. Each database has its own advantages and disadvantages. When it comes to the deployment part, MongoDB  was much easier to deploy, but there are many differences when comparing features.

I worked with other document databases including MongoDB and Firestore. Each database has its own advantages and disadvantages. When it comes to deployment, MongoDB was much easier to deploy, but there are significant feature differences.

I prefer both, but for complex applications requiring minimal downtime, I prefer Couchbase. If there is room for downtime, I would choose MongoDB.

It is a good solution, but as every product needs improvement, this also needs some enhancement. It is a good product. I rate Couchbase seven out of ten.

I have two use cases right now. I have a shopping list app where users can share their lists, so I used the Sync feature with Sync Gateway.

In another product, I use what they call N1QL, which is a query language, and I use it to check if ads are available to show to a user. In one part of the product, I only use the Sync Gateway, and in another part, I use N1QL to query the database.

It just works. I used other products and they didn't do what Couchbase  does. It works out of sight once everything is set up. When the user makes changes on their list in the app on their mobile phone, it syncs straight away. If there's an internet interruption, it resumes as soon as internet is available. I didn't have to do anything as a developer.

It's great because it's very different from MySQL  where you have to update tables. With document type databases, you just say there's a new element in your document, and that's fine. It's really good to use.

What is missing is that they have a new version, Couchbase  Mobile three, but they haven't really updated or provided help or documentation about what needs to change to update to the latest mobile version.

I'm looking into geospatial applications, and I know that Postgres has it more natively than Couchbase. However, I haven't done any testing yet to determine if I should switch databases or if Couchbase is fast enough with geospatial documents.

I have been using the solution for nine years.

Over the past years, it just worked. I updated the servers and versions, and if it wouldn't work, I would look for other solutions, but for now it runs fine every day, every minute of the day. That is really the single reason I haven't looked anywhere else.

Once it's set up, it's easy to use, and there are no headaches. I would recommend it. There might be people I wouldn't recommend it to who don't know anything about Linux or how to set up servers. They might need to go a different route, perhaps to the cloud, which is easier to use.

I've got millions of documents, and my servers are mostly idle, so it's really fine.

There was a service from Dropbox  about 10 years ago. Just before I switched to Couchbase, that was sunset. I tried Firebase back then. They had a sync service too, but it was only partly offline. Only partly the data was available on the device, and querying wasn't really supported. This is what I knew 10 years ago, and I didn't look at different products during those 10 years. I was really happy with Couchbase.

I'd say it's a steep learning curve first, and there are three things to set up that take time. But once this is all done, it's really easy. There's no more maintenance or worrying that things don't work as advertised. They just work, which is a lot better than having a product that's easier to use at first but then afterwards you still have headaches, so I prefer Couchbase a lot to other products I tried in the past.

It's a lot to learn and to wire everything up, but that is with every good product, you've got to study. It's similar to studying English to speak it properly.

I've been on the enterprise plan, and I think it was a five-figure amount a year. It turns out that I'm totally fine not having this enterprise account.

That was years ago when I had the enterprise plan, and it wasn't really stable then. I think it was around 2018. They did update, and since then, I haven't had any problems anymore.

Currently, I only use it in a datacenter, not on AWS . The reason being is that when I started using Couchbase, they insisted on running Couchbase on bare metal servers, not on VMs or in a Docker  container, so Couchbase has the full resources from a server. At the time, they didn't have any offers for AWS , such as Couchbase Capella . I'm really happy using it on premises.

I haven't used graphs yet. I use key value and document based functionality, and I actually used it 10 years ago. Now it's second nature to me.

I'll continue to explore using Couchbase, particularly looking into geospatial applications. While I know that Postgres has more native support for those uses, I haven't yet tested if Couchbase is fast enough with geospatial documents.

I rate Couchbase a nine out of ten.