Overall Satisfaction with Couchbase
Couchbase was originally selected to be the OLTP database to be used with "the experience engine" to hold the guest information, messaging, activity records, tags/classifications and related information pertaining to the guest experience. We initially used Couchbase prior to the creation of N1QL, and have used its core data services, views (now deprecated), N1QL, and XDCR and SyncGateway functionality. (Our use of couch-base included multi-instance replication). More recently, we've also worked with its event functionality and transactional support (a relatively new addition to its SDK).
- As a sharded key/value store for json documents, its both performant and scalable.
- The N1QL engine performs poorly compared to SQL engines due to the number of interactions needed, so if your use case involves the need for a lot of SQL-like query activity as opposed to the direct fetch of data in the form of a key/value map you may want to consider a RDBMS that has support for json data types so that you can more easily mix the use of relational and non-relational approaches to data access.
- You have to be careful when using multiple capabilities (e.g. transactions with Sync Gateway) as you will typically run into problems where one technology may not operate correctly in combination with another.
- There are quality problems with some newly released features, so be careful with being an early adopter unless you really need the capability. We somewhat desperately adopted the use of transactions, but went through multiple bughunt cycles with Couchbase working the kinks out.
- 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.
BerkeleyDB, Mongo
Do you think Couchbase Server delivers good value for the price?
Not sure
Are you happy with Couchbase Server's feature set?
Yes
Did Couchbase Server live up to sales and marketing promises?
I wasn't involved with the selection/purchase process
Did implementation of Couchbase Server go as expected?
No
Would you buy Couchbase Server again?
No