Apache CouchDB is an HTTP + JSON document database with Map Reduce views and bi-directional replication. The Couch Replication Protocol is implemented in a variety of projects and products that span computing environments from globally distributed server-clusters, over mobile phones to web browsers.
N/A
Couchbase Server
Score 8.7 out of 10
N/A
Couchbase Server is a cloud-native, distributed database that fuses the strengths of relational databases such as SQL and ACID transactions with JSON flexibility and scale that defines NoSQL. It is available as a service in commercial clouds and supports hybrid and private cloud deployments.
N/A
Pricing
Apache CouchDB
Couchbase Server
Editions & Modules
No answers on this topic
No answers on this topic
Offerings
Pricing Offerings
CouchDB
Couchbase Server
Free Trial
No
Yes
Free/Freemium Version
No
Yes
Premium Consulting/Integration Services
No
No
Entry-level Setup Fee
No setup fee
Optional
Additional Details
—
—
More Pricing Information
Community Pulse
Apache CouchDB
Couchbase Server
Considered Both Products
CouchDB
Verified User
Anonymous
Chose CouchDB
Open Source, and freely able to install it on any OS you desire (the big 3, anyways) CouchDB was selected for that, it's early-adoption of JSON and its mobile-friendly environment. Also, I have used it off and on in various non-professional projects, and it was really one of …
Compared to MongoDB, CouchDB's Map-Reduce paradigm poses a steeper learning curve for SQL users. However, CouchDB's master-master replication is an advantage of implementing a load-balanced solution. Even though, currently, CouchDB has strong community support, as an open …
MongoDB and CouchDB are both document stores, but their concurrency models and ability to scale are very different. MongoDB cannot replicate / shard over unreliable links and network partitions have been the cause of data loss in the past. MongoDB has an easier query language …
It has been 5+ years since we chose CouchDB. We looked an MongoDB, Cassandra, and probably some others. At the end of the day, the performance, power potential, and simplicity of CouchDB made it a simple choice for our needs. No one should use just because we did. As I said …
S3 blew this out of the water, we can get over 30 files a second, almost no failures, auto backed up, don't need our own server, and a much simpler interface with PHP Laravel.
We looked at MongoDB and Firebase. MongoDB gives us the best working db engine with a very intuitive design. However, it does not work as well offline. Firebase was extremely hard to create searching and indexing. Using a third-party to search didn't work for us or at least it …
I have briefly used MongoDB in other products, and it proved that it had better integration capabilities with Ruby on Rails and node.js software platforms, more than CouchDB. But I never had the chance to actually replace CouchDB with MongoDB in the current product to see what …
The project we are developing with Couchbase, was very inconsistent for few years of the beginning. We had to change data model multiple times. We knew this before starting the project. So we had to choose a NoSQL solution. We also wanted a syncing solution. After some research …
Couchbase could outperform it's competition considerably for database reads and writes. Full text searches were still faster in Elasticsearch but this is more of a feature than a base platform requirement for us.
At the time, Couchbase seemed the most mature of the NoSQL products and would allow us to achieve the goal of improving data access times for our products and services, giving the most benefit to our customers. MySQL was starting to be the bottleneck in our system performance …
Easy to deploy and manage. Clustering and replication is fairly simple and straightforward. According to developers, Couchbase scored higher points compared to the other products that we evaluated.
The Apache Cassandra was one type of product used in our company for a couple of use-cases. The Aerospike is something we [analyzed] not so long time ago as an interesting alternative, due to its performance characteristics. The Oracle Coherence was and is still being used for …
Single console for managing multi-cluster and multi-cloud deployment options and [the] ability to secure and isolate database information in a secure environment to prevent undefined access is great. Analyzing and delivering information and fast access and processing data …
Experience with DataStax Cassandra was seamless, but the cost and effort to support it was not justified. Also commercial process experience with Couchbase was much better. ActiveSpaces is a good technology for big TIBCO shop, but keeping with the lifecycle of it is not easy. I …
A strategic company, upcoming products, enhanced concepts. Couchbase is a single platform offering many different smaller products together viz Full-Text Search, Analytics, Eventing, Indexing, Querying, Integration with other products.
I'm not qualified enough to make a meaningful comparison, but 2 years after, I hear regularly about issues on Mongo from the other teams, especially on the SRE side. On our side, not much to say, except that it works. Ram, CPU, disk behave like expected. Same for bandwidth. …
It's good as a general JSON document store and basic map/reduce system. For more specialized tasks like message queuing, graph traversal, streaming metrics aggregation, or arbitrary table joins, I'd recommend another database.
Best suited when edge devices have interrupted internet connection. And Couchbase provides reliable data transfer. If used for attachment Couchbase has a very poor offering. A hard limit of 20 MB is not okay. They have the best conflict resolution but not so great query language on Couchbase lite.
Cluster sizing during the design phase can be improved, especially if the client lacks prior experience. Vendor consultants are very meticulous in order to provide best of class performance and response time, although some more real-world pragmatic approach is often needed.
Couchbase Lite 2 went thru a major revamp, which broke the compatibility of the applications with some features removed and other changed. That needed development teams working to refactor the applications.
As a highly distributed database system, CouchDB naturally has strong high availability with traffic load-balancing capability. It is also easy to scale and replicate data in a cluster for redundancy. However, there is still some room for query performance improvement in the future.
I rarely actually use Couchbase Server, I just stay up-to-date with the features that it provides. However, when the need arises for a NoSQL datastore, then I will strongly consider it as an option
Couchdb is very simple to use and the features are also reduced but well implemented. In order to use it the way its designed, the ui is adequate and easy. Of course, there are some other task that can't be performed through the admin ui but the minimalistic design allows you to use external libraries to develop custom scripts
Couchbase has been quite a usable for our implementation. We had similar experience with our previous "trial" implementation, however it was short lived.
Couchbase has so far exceeded expectation. Our implementation team is more confident than ever before.
When we are Live for more than 6 months, I'm hoping to enhance this rating.
One of Couchbase’s greatest assets is its performance with large datasets. Properly set up with well-sized clusters, it is also highly reliable and scalable. User management could be better though, and security often feels like an afterthought. Couchbase has improved tremendously since we started using it, so I am sure that these issues will be ironed out.
I haven't had many opportunities to request support, I will look forward to better the rating. We have technical development and integration team who reach out directly to TAM at Couchbase.
it support is minimal also hw requirements. Also for development, we can have databases replicated everywhere and the replication is automagical. once you set up the security and the rules for replication, you are ready to go. The absence of a model let you build your app the way you want it
Open Source, and freely able to install it on any OS you desire (the big 3, anyways) CouchDB was selected for that, it's early-adoption of JSON and its mobile-friendly environment. Also, I have used it off and on in various non-professional projects, and it was really one of the first exposure to databases in my career
Couchbase could outperform it's competition considerably for database reads and writes. Full text searches were still faster in Elasticsearch but this is more of a feature than a base platform requirement for us.
So far, the way that we mange and upgrade our clusters has be very smooth. It works like a dream when we use it in concert with AWS and their EC2 machines. Having access to powerful instances along side the Couchbase interface is amazing and allows us to do rebalances or maintenance without a worry
Biggest impact on our business has been that CouchDB has been pretty invisible from a cost or issues perspective. It just works.
We use the Apache releases, so it's free. Of course there is a cost to "free" - we have invested time to become fluent in using and understanding CouchDB. But we feel the investment was well worth the effort and we have a solid, fundamental technology to our products that "just works".
There are some things we do - SaaS vs self-hosting - that have probably been kept simple by using CouchDB. Overall, we are extremely happy with CouchDB.
There have been several areas of our application [that] really needed an ACID compliant database (e.g. strong transactional guarantees) that we thought we could work around while using Couchbase. [In my opinion] that turned out to be a poor bet. You need to be certain that the specific characteristics of a NoSQL database fit your problem.
Couchbase does eliminate the need for schema upgrades completely. I.e no downtime or conversion windows as you migrate your data model, adding attributes, etc. This helped with the deployment timeframe associated with DB changes.
The database is (apparently) a bit more of a space/memory consumer than originally anticipated. During deployments, we received constant pressure from Couchbase consulting teams to eliminate/reduce the number of indexes, and this was because any mutations to docs in a bucket must check for impact against all indexes. More recent years have started to address this with their "collections" features, which helps isolate indexes to specific sub-groupings of documents.