Couchbase Enterprise Reviews

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.

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. 

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. 

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. 

We manage our telecommunication application using the product. 

The product's most valuable features are its overall availability and robustness. It is highly available for support and does not impact our operations significantly during failures. It performs very well in terms of speed, particularly for write operations.

The platform's grouping features need improvement. Additionally, it supports only a few storage types, which presents challenges, particularly for I/O operations.

I have been working on Couchbase for the last two and a half years.

I have never encountered any stability issues for the product. 

Sometimes, the technical support team responds promptly and helps with incidents, but other times, they require multiple logs and take more time to provide root cause analysis.

Positive

The licensing cost of Couchbase is quite expensive compared to other databases.

The platform's migration process, including upgrades, is quite easy compared to other databases like PostgreSQL. 

I rate a six out of ten.

We're using Couchbase for general purposes and for caching.

The principal advantage of Couchbase for us is that we can have multiple database paradigms in the same product, without deploying multiple databases.

We also like that it has lower latency, when compared to its competitor: Cassandra.

We would like to have a better management of Kubernetes with the free, open source version of Couchbase. We don't have any major complaints other than that.

We've been dealing with Couchbase just very recently, approximately two months now.

Couchbase seems to be a stable product.

Couchbase does have an open source version, but it has some problems for deploying in Kubernetes, so we are thinking of going with the commercial version. We estimate that it's not very expensive, however, the pricing that you can get from the account managers, e.g. the public pricing, is a bit expensive.

We were able to evaluate Cassandra. When comparing the two: Couchbase is more general purpose, and it has a smaller latency, while Cassandra is easier to manage with the open source version in cluster environments.

We have only tested deployment for Couchbase. It's just in POC, so it's still too early to tell if the deployment is easy or complex, until we have deployed it in a production environment. It's currently not deployed fully.

We hope that Couchbase is scalable, as there are some studies that we have seen that mention its scalability, but as it's only in POC now, it's still difficult to know for sure.

We have not interacted with technical support yet, so I'm not able to give an evaluation for Couchbase support.

For now, I cannot say if I would recommend this product to others. It's still too early, e.g. it's better if we use it for more months, so we can have more information about it.

I'm rating Couchbase nine out of ten. I didn't give it a perfect score because the implementation schemas need to be improved, and we don't have much data currently.

I am using Couchbase for searching web services to find user metadata.

The most valuable feature of Couchbase is document indexing. It is better than MongoDB. Additionally, the solution is easy to use.

Couchbase could improve the design of the UI because it should be optimized for viewing statistics or a similar feature.

I have been using Couchbase for approximately two years.

The stability of the solution depends on what environment it is deployed in.

I rate the stability of Couchbase an eight out of ten.

The solution scales well for my usage.

We have five people using this solution in my company.

I rate the scalability of Couchbase an eight out of ten.

I have not used the support from Couchbase. If I encounter issues I used the internet for the use cases that I struggle with to find solutions.

I have used MongoDB previously. Couchbase has an administration panel that is more advanced than MongoDB and allows for more cultivation.

In a runtime environment such as Couchbase, the indexing system can struggle when dealing with large numbers of documents, such as two or three million. This can lead to a delay in the intake of documents. However, I have not used MongoDB in a scenario where such a large number of documents is necessary.

I used Docker to help me set up Couchbase and it was easy. The full process takes 10 to 15 minutes to implement.

I rate the initial setup of Couchbase a ten out of ten.

When considering a NoSQL database, I would recommend MongoDB as the first choice. However, if additional tools or functionalities are needed, then Couchbase may be a better option.

I rate Couchbase a seven out of ten.