Couchbase Enterprise Reviews

My main use case for Couchbase Enterprise is to store sessions. Specifically, I utilize the product's session management function to store user experience sessions in Couchbase, and for the profiles so that I can discover the peer node. For long timers, I use Couchbase Enterprise.

A specific example of how Couchbase Enterprise fits into my session management and profile discovery processes is that the session management of the discovery profile functions in distributed systems, where the peer node can change, meaning it's not systematic data that can be stored. Therefore, Couchbase Enterprise is a perfect solution for me to store that session in the database.

The best features Couchbase Enterprise offers for my use cases are user profile and session management.

For user profiles and session management, the features of Couchbase Enterprise that make it stand out for me are its scalability, performance, and flexibility. I would add that Couchbase Enterprise is reliable; being a key-value store makes it especially useful for me. Additionally, it can be set up on Azure, AWS, or on-premise, which is a great feature.

Couchbase Enterprise has positively impacted my organization by being easy to set up and use, making the GUI perfect for everyone, which enhances user experience. This ease of use translates into actual outcomes, such as saving my team time for analytics. The GUI saves me a lot of time since I can directly check the document in the key-value store in JSON format, which allows anyone to access it. Consequently, that reduces team time and errors, with measurable benefits.

There is room for improvement from a perspective of needing enhancements. Couchbase Enterprise is fine and working well, so I do not see much improvement needed from the organizational perspective of where I am working or on the product I am using. The reason I chose nine out of ten is that there should be a dedicated feature that allows it to come up with a single click for the ease of everyone, which is why I leave that one point off.

I have been using Couchbase Enterprise for almost ten years.

Couchbase Enterprise is stable.

The scalability of Couchbase Enterprise is good.

The customer support for Couchbase Enterprise is great.

Couchbase Enterprise has positively impacted my organization by being easy to set up and use, making the GUI perfect for everyone, which enhances user experience.

On-premises

We used Couchbase as the primary data storage. Since our company was in the gaming industry, Couchbase stored data on players and related to games, levels, and similar objects for our mobile applications, aka games. There was a synchronization in place between Couchbase and another database, Elasticsearch. Some indices from Couchbase were periodically replicated to Elasticsearch.

I liked that Couchbase was stable and consistent, as much as possible with a NoSQL database. We didn't experience any downtime. Writing to the database was something we could rely on, and the database maintained reliable storage. This reliability was essential, giving us a good level of reassurance regarding data presence. Couchbase provided consistent productivity as a finished solution that worked well.

Couchbase needs to improve the consistent reliability of the replication feature. Sometimes, the replications would be delayed. This delay meant that data on another database, Elasticsearch, was not always up to date, which could be noticed in the games. Making replications more timely and consistent would be beneficial.

I worked with Couchbase at my last workplace for two and a half years.

Couchbase was a stable solution for us. We didn't experience any downtime, and the data stayed there consistently.

I would rate the scalability as ten out of ten. It was easily scalable, which is expected from a NoSQL database, and very important as player numbers could grow, so we needed to accommodate all that data.

We never contacted tech support while I was at the company. However, we used the documentation, which was well-written and clear. I'd rate it ten out of ten.

Positive

The DevOps team handled the implementation.

Couchbase maintained consistent productivity as a finished solution that worked well, saving us time dealing with something less efficient.

I would rate Couchbase nine out of ten, given some small hiccups. For example, the replication feature needs to operate in a more timely and consistent manner. Overall, I would rate the solution nine out of ten.

Public Cloud

Amazon Web Services (AWS)

In my company, we use the enterprise version of Couchbase, and it is used across the organization for its database operations. We do only use the NoSQL database, not Couchbase Capella.

The tool is mostly for document-based storage of Cisco, which is a retail company. We manage a lot of product information and send a lot of metadata that we generate for all of our orders, including baskets and other aspects. We use Couchbase heavily for document-based storage purposes.

The most valuable feature of the solution stems from the ease of operation with Couchbase, and it has a lot of extensive features that it provides because it's not a document-based storage. We can also do basic operations on those documents, like indexing important fields, a full-text search, and advanced machine learning operations, like vector search. The tool is pretty easy to use and work with as it is a schema-less tool, so we don't have to work too much on defining the schema for the tables or the documents. It is very easy to onboard the tool to work for the new teams. It is a very extensible tool. My company gets a lot of good support from them as well, and their documentation is also pretty good, which we have found. Compared to other tools, such as the best document-based storage, MongoDB, and others, Couchbase works pretty well. Couchbase also provides good offerings in terms of the different features that we need from different DBs, like searching operations and materialized views. The tool works pretty well. The tool also provides very good latency on high loads. The scalability and the reliability are also other important aspects of the tool.

With some of the operations, we used to face some challenges with scalability. Although it worked pretty well, in some scenarios, we noticed issues where the replications and the sharding were not happening correctly. In recent versions, we also faced some issues in terms of enabling advanced operations like FTS and vectors. Although it works pretty well, in some places, we do face challenges, especially on a heavy scale. I think all issues are being addressed in the latest version of Couchbase.

The resources are not that good for Couchbase. The tool's documentation is pretty extensive, but if you go for any kind of courses or tutorials, there are very limited resources available. It also becomes a little bit challenging for new people to get onboard into it. MongoDB and other such open-source database tools perform really well as they're really widely adopted, and they have resources available to get you onboarded pretty quickly. I think that we do face some challenges with Couchbase, but luckily, we have the tool's enterprise version solution, so we get all the support from the product team.

I have been using Couchbase for two or three years. I am a customer of Couchbase.

I rate the technical support a nine out of ten.

Positive

The product's initial setup phase is easy.

The solution can be deployed in two to three minutes.

I suggest the tool to others as it is heavily, working a lot on improving the database framework.

The tool offers support for multiple data models.

We do need to maintain the tool as there is a need to upgrade it, and we do need to do continuous patching. We do have a central team for Couchbase, and they manage it for us. They are actively working with Couchbase's enterprise team to do all those operations, like patching, server upgrade, and backup, but it all requires some kind of support.

The tool has some AI capabilities, as you can do vector search, semantic search, groupings, and using open-source models and enabling them on the database so that we can structure our data better and do things like advanced search operations.

I rate the tool an eight out of ten.

I can see Couchbase is being used for various use cases, primarily to enhance data handling capabilities.

The best thing about Couchbase is its versatility in handling data.

Overall as a tool, I see room for improvement in Couchbase in certain aspects.

I have been using Couchbase for some time now.

When asked about stability issues with Couchbase regarding bugs or system breakdowns, this was specifically discussed.

Regarding the scalability of Couchbase, I think it shows great potential for growth.

For their support, I would rate them a 7 out of 10. I gave this rating because there are some areas where I think they could improve.

Neutral

The deployment and initial setup of Couchbase is straightforward, though some people might see it as complex.

The question was raised about whether Couchbase is completely free or if there are any hidden fees.

The discussion included whether Cassandra was being used in conjunction with Couchbase.

I am a user of Couchbase and would recommend it to other people. Giving practical insights would be valuable advice for anyone new to Couchbase.

On a scale of 1-10, I rate Couchbase an 8.

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.

Positive

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.

Hybrid Cloud

Google

We're in the middle of building out a persistent cache layer using Couchbase. That's across multiple international regions, but we have other instances where we're using it for data stores and some for its analytics features. 

There are a couple of benefits. It's cheaper than, for instance, Redis for us to implement a caching solution. 

The other benefit that I've noticed is the ability built into the tool to do data replication across the enterprise. If I've something in AsiaPac, something in NAM, and something in EMEA, I don't have to set up the infrastructure, buy the software, and buy the hardware outside of my database to be able to replicate between the three regions. That also applies to disaster recovery. It's built-in, and I just specify the bucket that I want to copy, and it works. So, price, extensibility, and scalability are the benefits of this solution.

The other benefit that we've noticed is speed-to-market. I began a PoC in October of last year, and there were four sprints in the PoC. By the end of the year, we were only expecting to be done with the first sprint, but we were already through the first sprint and about to complete the second sprint. The implementation time is very less. The biggest challenge we had was with indexes.

The whole stack is valuable, but the portion of the stack that we're finding really handy is the analytics engine because that allows us to take and pre-build views. One of the use cases that we're doing currently is for reporting, and in some cases, the users are having to come up with complex joins and complex. We call them formulas. They are not just joins. There are filters, transformations, and those sorts of things, which take a considerable period of time to perform. So, we use the analytics engine to pre-build that data for them so that when they do the reports, they're just selecting the fields of the data that they need as opposed to having to build the data that they need. We can present it in a single view, and they can then just select A, B, C, D, E, F, and G.

Their security model leaves something to be desired. Their indexes could use some work, but once we found out what was going on with them, it became second. So, the biggest one so far is integrating with an external security model and having a security model that you can use. I know there's a performance hit with it, but if possible, I'd like to be able to go down to potentially a column-level instance. I'd like to be able to set up entitlements based on that. I can do that currently, but it's a little bit convoluted in the way I have to do it. It can become, from a large enterprise standpoint, a bit unwieldy in the way I have to manage it to get it to work.

The other thing that they could really improve is their documentation. Their online documentation or just documentation in general is pretty bad. The online documentation is very confusing. It's not very intuitive to find information. There are no white papers on best practices for doing things. As much as everybody rags on IBM, considering the various different software products that IBM has, their documentation, for the most part, is very good. You can find many white papers, and it's very easy to find things, whereas, with Couchbase, the whole documentation setup is very confusing. It's not usable, for the most part.

They should support native S3 ingestion into the default bucket or into the system. Currently, when I want to look at S3 stuff, I use the analytics engine, and that works fine. However, when I want to use S3 as a landing point to be able to load into the default Couchbase—not use in the analytics engine but just to import into Couchbase—there's no native way of having Couchbase talk to S3 to get JSON documents out and loaded into the data store. So, I've to use a third-party product called Data Sync to be able to pull stuff out of S3. The integration options aren't as robust as they probably need to be. They only have about two.

It's easy to deploy. Where the challenge comes in is when you start putting data in, doing the indexes, and doing the integration with systems. Integration is one of their weakest points. Natively, there should be a wide range of integration options to be able to get data in. Once you get the data in, it's really easy to get the data out. It's very simple. It's a JDBC, etc. It's just that the integration to get the data in can be a challenge.

In my portion of the company, we've been using it for about six months, but we've had it for a couple of years in other portions.

It's very stable for the most part. There were some edge cases that we did, which were more our fault than the product's. There are some bugs that we found that Couchbase is addressing in version 7.11, but for the most part, it's stable. We haven't had any major issues with stability.

It's very scalable. When I go to production with this PoC, ultimately, I will have 150 terabytes worth of active data that will be accessed by the solution. Couchbase has told us we're one of the larger or largest instances of Couchbase out there. So, it's very scalable. There are some challenges with how you do that scalability, but once you figure out the way you have to structure your data to do that, it's very scalable. You can't just throw 150 terabytes worth of data into a single Couchbase instance and expect it to perform. It just won't. So, you have to look at how to structure your data. You have to look at how you implement your clusters. You don't want every single one of your stacks—the analytics engine, the query engine, the index engine, and the data engine—running in the same nodes. You want to look at your performance and maybe put your analytics engine on one node, your real-time query or your natural language query on another node, and your index service on another. You need to look at what performance you want and how your data is structured, but once you get down to how to do that, it's very scalable. With the PoC, I got a total of three people who are administering to see that it's going to lead to 150 terabytes. So, we don't need a huge admin staff.

Across the enterprise, there are probably 150,000 people, and most of them are just application users who are querying it to get reporting data or getting data for their dashboards. Ultimately, they're just users of the application that we put in front of Couchbase to get the data out. There are a couple of hundred admins.  Most of them are administrators. There are some people who are the equivalent of DBAs who onboard new data sets, set up indexes, etc. We have a couple of hundred across the entire enterprise. 

It's being used throughout the enterprise, and our usage of it's scaling up considerably. Most of it has been a line of business here, a line of business there, etc. With this PoC, we are moving towards having this across the whole enterprise for our data caching as well as data reporting. So, we are ramping this up. We are, so far, very happy with what we're seeing and what we're getting.

So far, they've been okay. They haven't been the best. We've had to play what I call the 800-pound gorilla a couple of times to get focus on our problems, but once I played the 800-pound gorilla initially, they've been very responsive to our issues and helped us resolve issues. We found bugs, and they're working on solving those bugs. Of course, we're a big bank implementing a big solution. So, we're going to get a little bit of a different experience than a mom-and-pop credit union, but for the most part, they're about as typical as any support organization.

We also use Redis, but we are getting rid of it. The reason why we're getting rid of Redis is that it's not scalable. It's not a true data cache and does not handle large volumes of data for reporting very well. It doesn't handle complex data very well. It's literally built as a data cache only, and for programming, and it acts as thus. So, if we went in and did a PoC where we loaded 900 megabytes into the Redis cache, and name, address, city, state, and zip were the tags, that data took nine hours to load into the cache. After we literally changed the tag names for the data to A, B, C, D, E, F, and G, that nine hours of run took nine minutes to run, but we can't expose that data for the enterprise and the business to use by having somebody look at a site and say, "oh, an A is a name, and a B is a city." So, we're phasing out Redis because of that and because of the cost. 

We're still using Hadoop. We are going to phase out Hadoop, but that's more of a long-term project. That's simply because it doesn't deliver what it promised. It's very easy to get data into Hadoop, but it's almost impossible to get data out of Hadoop for reporting in a real-time fashion. It's more along the lines of a batch-level system, and there are multiple limitations to that. 

We are still using Mongo, though not as much. Mongo is a special thing. We use it, but we want to limit it simply because there are a lot of problems. From the SQL to get stuff out of Mongo to the persistence layer to the replication isn't easy. It's very good for dedicated tasks, but when it comes to an enterprise stack, it's not very good at what we need it to do. 

Installing the software and getting it up to a base level and running takes about a day. It's very easy to figure out how to deploy it. 

We've seen an ROI. We're able to reduce our costs. We've been able to improve our speed-to-market. Barring the integration work, we've been able to get rid of Redis and the cost of that. So, we've seen an ROI.

It seems very reasonable. It's a lot cheaper than Redis, but we've got an enterprise license. So, it's about normal. It's not outrageous in price as far as we've seen.

From Couchbase, there's no additional fee as far as I'm aware, but when you're integrating, there's an additional fee because a lot of times, they don't have an integration stack. They literally have two ways of getting data loaded in. It can be done either via the API or via a bulk load, and there's a way for them to read from Kafka, but instead of having to stream to Kafka, if you want to get it in or set up a batch file interface, your choices are limited as to how to integrate. So, you end up going to vendors like CData and buying their Data Sync application to be able to get data out of, for instance, an Oracle database, or natively out of Hadoop. That's what we ended up having to do because of the S3 issue. So, there are integration costs, which are not part of the core, that you might have to face. 

Engage Couchbase-based technical staff soon and often. They're your best source of information. Don't struggle with trying to find it in the documentation because the online documentation is not intuitive. The other thing is to look at your data and see how your data is structured. Understand your data, and understand what you're trying to do from the get-go. Bring somebody on board who has experience implementing Couchbase. That has been a real help for us. We've got an on-staff SME with extensive background, but we also have a lot of communication with Couchbase itself. Couchbase presales have been good at helping us through things. So, use the resources that are there and engage them, and know your data—how it's structured and how you want to use it.

I'd rate it an eight out of ten. I don't like giving tens because nothing is ever perfect. There is also the difficulty of having to engage third parties outside of Couchbase to do the integration stuff, but overall, I'm very pleased and very happy with them.

On-premises

I was working on a game called Infinite Fleet and the backend for that particular game was written in Golang and our database of choice was Couchbase.

We were dealing with a lot of unstructured data and were leveraging the load balancing capabilities of Couchbase. The data that is stored on our Couchbase instances includes player profiles and metrics. 

We have a total of 25 developers who use it.

The main advantages were associated with it being a no SQL database. It helped us send out metrics or rewards to multiple players in our game at a very low latency. I pushed a lot of updates onto the Couchbase cluster and it performed very well. I was able to cater to 50,000 people within minutes and update our Couchbase DB very easily.

The query language for Couchbase has been valuable for me. I really enjoyed it because it helped me track down a lot of play and NFT records easily.

One thing that could improved upon is the level of concurrency. The documentation for this solution could also be improved. 

I have used this solution for one year. 

I would rate the stability of this solution a seven out of ten.

I would rate the scalability of this solution an eight out of ten. 

I have not had much experience with the Couchbase support team. 

I have previously used Mongo and DynamoDB. We switched to Couchbase mainly because it offers good documentation and is an out of the box solution so can be used straight away. It is also very affordable.

Yes, we have experienced a return on investment. 

I would rate this solution a nine out of ten for pricing as it is affordable. 

I would advise others to stick to the conventional libraries that you have or that are provided by Couchbase itself. I would advise against using third party solutions on top of Couchbase. Read through all the documentation to ensure you are aware of any conditions that are important to your environment. 

Public Cloud

Amazon Web Services (AWS)

My use case of Couchbase is supporting around 920 nodes, including 420 clusters. I lead an off-shore team and my client is in the retail domain. In my current project, around 30 different applications are using Couchbase with 5 DBAs. All are e-commerce. We are customers of Couchbase and I'm a Couchbase administrator. 

A great feature is Sync Gateway, which supports the mobile application. In previous versions we had to rebuild indexes for the patching activity or the upgrade activity. The indexes automatically rebuild now once the node is added to the Couchbase cluster. Configuration in Couchbase is also quicker in comparison to the other NoSQL databases. This is a user-friendly solution. 

Customer support can be improved because if we have any kind of problem and raise a ticket, there's a lag in response time. I've also found that there is some wastage because when we provision the clusters as per the request from the application team, they provide too much memory, CPUs and displays.  Couchbase doesn't use that much memory or CPU. Maybe they can do some kind of capacity planning to solve that. I'd like to see our application team have non-DBA access so that the DBAs work with the application team for a minimal amount of time. 

I've been using this solution for over five years. 

Couchbase provides high stability and performance. It runs 24/7 without any down time. If one node goes down, then the data will be transferred to other nodes in the clusters. 

Couchbase is a scalable product. We're currently expanding our use so that  all the applications which were in Mongo and Postgres, are currently being moved to  Couchbase. 

The customer support is quite good. 

Positive

When we first implemented Couchbase, the cost was less than the other RDBMS, whether it was Oracle, DB2 or SQL servers. We also received 24/7 free support so there were no extra charges. 

The initial setup is easy. We build the Couchbase clusters using a data node, query or index. It depends on the key metrics which the application team wants. Deployment takes around 5-10 minutes in the web console. Following that, we can add in a number of nodes and join the clusters.

For the on-premises solution, we have a separate Linux team for any maintenance activity. We have a separate team for the cloud. Whenever we are doing patching activity, we have to remove-and-rebalance on the particular node where the OS team performs the patch. 

I think we are getting our money's worth from the solution. 

Couchbase is user-friendly when compared to the other RDBMS that require maintenance to improve the queries. With Couchbase, everything comes in the document tree so we don't need to do any REORG or RUNSTATS.

I rate this solution nine out of 10 because it's more flexible and efficient and we can do automations on Couchbase in many ways. 

Hybrid Cloud

In the beginning, we used this solution to store configuration data. We had a system that we used for management for our platforms. We then needed a system that could help with configuration of platforms. We were looking at a couple of different options of how to store those configurations dynamically. We have 17 people that use this solution in total. 

It took us a while to figure out how to use this solution. 

I can input any kind of document into the solution and it is integrated using a dynamic API. This has been the most valuable aspect of using this solution. 

You do need something that will integrate with Couchbase separate to your front end application and we use Angular. Our APIs integrate with Couchbase using the SDKs that they have available. I mainly use their dot net SDK.

The scripting language for this solution could be improved. A big selling point is that they're like SQL server but there is still quite a lot of missing functionality. They are slowly adding additional functionality but without it, the solution ca be complex to use. 

Secondly, this solution does not function well on a Windows based server or infrastructure. Hosting it on a Windows server can max out your CPU and bring down your cluster. This is one of the main reasons that we stepped away from having that in this kind of environment as well as needing to buy a license for support. There is also a lack of documentation. 

We have been using this solution for three years. 

The challenging aspect is knowing how the indexes work and if you create buckets, knowing what kind of indexes to create to query your data. There are a number of different aspects that impact its stability. I would rate it a six out of ten for stability. 

This is a scalable solution. Adding nodes is very simple. I would rate it a seven out of ten. 

We have moved to using Elasticsearch which gives us flexibility that we did not get with a no SQL kind of structure. 

You can connect to Elasticsearch using AlloyDB for solutions like PowerBI. It also gives us more features in terms of monitoring. 

The initial setup was very easy, especially on Windows. The biggest aspect of the solution is tuning it and understanding how it behaves. If something happens, it drops and switches off all your nodes and you need a rebalance. The biggest difficulty with the platform out of the box is getting it to run in a stable way. You can run it or you can get it up and running on your local machine very quickly, but having that set up for a production environment is a different story.

I would rate the setup of the solution a seven out of ten. 

Initially, we used the open source version to see how it works and what the support is like before committing to an enterprise license. That's why a lot of companies go for Microsoft SQL server because you buy the licenses and get the support and have a community to help you. I wouldn't say Couchbase offers good value for money. 

We opted for a no SQL kind of data storage. We looked at Redis and MongoDB and opted for Couchbase because it had SQL integrations, programming language and scripting language.

I would rate Couchbase a seven out of ten. It's not a bad product but it depends what you're using to run it on. The time and effort that you need to spend learning the product and how to fine tune it wasn't worth it for us. 

I would rate it a seven out of ten. 

Initially we were using the on-premise Couchbase Server which was maintained by the organisation with assistance from a consultant from Couchbase. After they came up with the cloud version of Couchbase called Capella, it was decided to migrate there to reduce the maintenance cost and to take advantage of the advanced features the product offers. 

Couchbase Capella offered distinct advantages like ease of horizontal and vertical autoscaling, ease of querying using the SQL++ language (which is not hard to learn), and the flexibility it offers while being hosted in the cloud and being served by the parent company.

We moved from a relational database to a non-relational database, where there is no format for storage of data, no linking of different tables, and not too much effort is required in learning the query language. This has made data storage an easier process and querying effort is optimum. 

Easy querying language. 

Easy to increase server capacity as per usage demand.

Easy UI interface.

Data storage is easy and we do not have to navigate different tables for extracting relational data.

Time to extract the data is faster than non-relational databases and hence there are fewer performance issues.

Earlier services were designed to be integrated with the non-relational databases and when a different type of database is introduced it is obvious that there will be issues in integrating with the existing infrastructure. Same was encountered when trying to integrate Couchbase and exhaustive testing of the setup was done to check for data integrity.

An area of improvement for Couchbase would be to integrate the 3 parts of the Couchbase server (Server, Sync Gateway and Couchbase Lite) into a single unit so the integration with the customer infrastructure becomes easier.

I have been using it for one year. 

For Couchbase server, nodes have to be created or reduced based on requirements, which is a technically complex task.

For Couchbase Capella, there are different combinations CPU and Memory available which can be configured as per requirements and hence it is more flexible. 

Couchbase could also improve with their technical support and provide project specific solutions rather than generic.

Positive

Couchbase is a good NoSQL server and I would recommend it to users, simply because if the simple way of storing the data (in the form of JSON) as well the easy process to retrieve it.

Customer support is good and they will help you in suggesting mitigation measures for most of the issues being faced by the project.

There is no major knowledge gap while transitioning to a non-relational database, knowledge of SQL querying and JSOn models are sufficient. 

Overall, I would rate it an eight out of ten.