A good tool for the right problem
August 19, 2021
A good tool for the right problem
Sr. Technical Architect
The Experience EngineLeisure, Travel & Tourism, 11-50 employees
Score 2 out of 10
Couchbase Enterprise Edition
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.
The data services APIs (i.e. distributed map) performs very well. The N1QL query capability does not perform as well because it was based on a distributed interaction between query service, indexing service, and related data service. Compared to databases like Oracle RAC, N1QL over a large distributed cluster doesn't end up performing as well as a simple SQL query from a relational database. This performance you will see depends on your role. The analytics capability was developed based on a different query engine which is significantly faster over a large data set, so if you stick with an architecture where key-based lookups are used with the OLTP engine, and all N1QL queries are run on a separate analytics cluster, that may be the best combination of performance characteristics.
Do you think Couchbase Server delivers good value for the price?
Are you happy with Couchbase Server's feature set?
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?
Would you buy Couchbase Server again?
Couchbase will work well if what you need is a high scale, highly available distributed map. This is what it started out as, and like many products it has sought to grow outward from that area of core competency, but many of those additions (e.g. N1QL) don't really perform as well as other database products that specifically fit that niche. If you're application can work well with a distributed map, its a good tool for that job, but beware the "it can do anything that other databases can do" angle.