Couchbase 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.

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. 

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.

In our current project, we use this solution in the healthcare field for the telemedical industry and in other projects in the automation industry.

The valuable features of Couchbase are the many documents and index types, and they made a lot of features available enabling us to use it as a complete solution for our needs.

There are some limitations to the database. The SQL database cannot handle real-time processing for critical IoT scenarios. What we have to do is store our data into the database then code it out, this wastes a lot of time.

We have recently started using the solution.

The solution has been reliable and stable.

We have not attempted to scale the solution at this time because we are a large company that needs more security. We are in the early stages of integrating DTS technology, our chosen security solution, once implemented we will begin scaling Couchbase.

The technical support has been responsive and they provide good support.

The installation could be difficult for some engineers that are brand new to the implementation because the reference documents are much harder to find than other solutions, such as MongoDB.

For the cloud-based solution, there are a number of options available when it comes to the frequency of license payments. You can purchase a license monthly, quarterly, and annually. Since our project includes IoT from another solution this pricing model could be complicated for us.

The price of this solution is better than some of the other competitors.

I have evaluated MongoDB and it is lacking some features that Couchbase has making it a complete solution. With MongoDB, we would need another solution to work alongside it to function the same as Couchbase.

I would recommend this solution to others.

I rate Couchbasean eight out of ten.

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.

There are many shifts and we use Couchbase to log that data whenever they travel from one place to another. We log the data and we merge it in the backend. That's how the application and everything works. If you are a temp person on one shift and you have logged data, we use the nearby API to connect them and to pull and push each other's data. 

We also use Couchbase for Android tablet to the cloud. 

The most valuable features are the ease of application and the merging of data.

I have tried multiple libraries in a demo they provide and it works fine, but when it merges with libraries, it creates a problem.

I have been using Couchbase for six to eight months. 

It is stable.

Couchbase is scalable. There are eight to ten users who use it in my company.

Their support is supportive. 

The initial setup was complex. It was a quick implementation. 

My recommendation of Couchbase would depend on the user's requirements. 

I would rate Couchbase an eight out of ten. 

We use it for data link utilization.

The horizontal scale is a major factor. We want to be able to expand our capacity horizontally.

The failover and failback could be a bit easier. When I looked at it last time, it had to be manually done. It also took over an hour for us to rebalance all the nodes.

It's pretty stable. We like it.

Scalability could be a bit more desirable. We are probably a little hardware limited.

With AWS, it might be better. We're also looking at DynamoDB as a possible replacement.

We also looked at MongoDB, some sort of eMemory, and cache layered with a traditional relational database for performance sake, because we churn a lot of data. We collect for each customer upwards of around 20GB/hour of data. Therefore, performance is important to us, so NoSQL eventually became the obvious choice.

The decision was between this solution and MongoDB. We chose this because it came with N1QL, which is their query language. Whereas MongoDB, at that time, did not come with any sort of query capability.

Couchbase is a good solution to a lot of problems, but you will have to do your own research on it. It does have the scalability. It fits most of our needs. Though, the performance could be quicker and better, especially in the querying process.

We actually have not used it with AWS. We just purchased directly with them, and we have our own hardware. As part of our solution, we are now looking to move some of the solution to AWS. We want to provide solutions to our customers and package it as a product, and it feels like a lot of people are asking for cloud as an option. Therefore, we are looking into cloud deployments instead of on-premise deployments.