Apologies it’s taken us so long to respond to this!
Historically, Couchbase has been used heavily as part of the overall data management strategy for financial services, banks, payment services, etc. The main benefit has been to leverage Couchbase for the types of workloads that traditional databases are not well suited for, and leave those databases to focus on what they were designed to do well.
As I’m sure you’re familiar with, there is a lot of “interactive” activity for a user or system before the final stage of actually moving money from one account to another. All of the searching for account information, available products, prices/rates, reviews, operational KPIs, etc has always been a great usage of Couchbase.
In addition, we are just about to release support for multi-document, distributed ACID transactions which will allow you to use Couchbase for an even wider variety of use cases and workloads.
There may still be use cases that relational databases are still well-suited to handle, and we very much expect them to continue doing so. However, if an application has some or all of the requirements that Couchbase was designed for (schema flexibility, multiple access patterns such as SQL-querying as well as Full-Text Search as well as Operational Analytics, mobile/embedded synchronisation, cloud/container infrastructure, geographic distribution of data, high availability, consistent low latency at high throughputs, etc) then we believe that application should be able to get the behavior it needs and expects whether that be from a normalized or de-normalized data model, strong or relaxed consistency, single or multi-document transactional reliability, in-memory or persistent.