To put it straight: Can counchbase be used as the main database for banking system or e-commerce system where you deal with money?
It’s a talk about ACID here and transactions.
User transfers money:
money has to be substracted and then added to other account( 1 transaction)
Customer buys item on e-commerce:
it’s the same, part of 1 transaction…
Can couchbase serve as complete relational database replacement in a system with a lot of relations and a lot of transactions providing at the same time better performance, scalability and consistency and all that it promises?
Because of course relations are used in 90% of applications.
There are many use cases on your website but they’re not precised and maybe they just use it in connection with some RDBMS.
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.