How can I archive strong consistency?


I as a developer am currently in a dispute about using couchbase as the main database and we also need the data to be fetched uptodate.

How can I archive strong consistency, or is there a design problem with couchbase?

Is there a special vBucket setup or special handling in the source code?

Thanks for you help…

As discussed in the documentation, all of the KV APIs allow you to specify Durability Requirements. Also, @matthew.groves has a good blog that goes into some of the details of the semantics.

There is a design philosophy behind this. Not all requests from the app are equal, and only the application developer has the context to know if in memory on two nodes is considered durable enough or if on disk on four nodes is considered durable enough. Unlike traditional databases where this is only express-able at the database configuration/definition level, in Couchbase you can scope it to the operation. In systems like Couchbase, the app is more in control of things like schema, durability and so on.

This makes sense, in our opinion, as some updates are simple status/telemetry that will be updated with more details soon and you don’t want to pay the latency cost and others are very important and your app will want to handle very carefully any errors that come about. Of course, there are some stages in between.

Worth thinking about also: the tradeoff for durability is availability. Here in the modern, distributed world-- do you consider it durable if it’s ‘on disk’ on an ephemeral node? Probably not. Also, what will you do if, at least temporarily, a mutation can’t make it to multiple nodes. The good thing about our design is you are in control. (I should probably write a blog on this!)

I should also mention that for Couchbase Server EE subscribers, there is a Multi-Cluster for Java component that enables high availability writes (among other things) across clusters.

Hope that helps and feel free to ask any additional questions.


Hi Robin,

To quote from Don Pinto’s 10 Things Developers Should Know about Couchbase,

Document access in Couchbase is strongly consistent, query access is eventually consistent.

(With N1QL, queries can be strongly consistent too… more on that below.)

During normal operating conditions, when using the Couchbase Data Service (Key/Value API) you can immediately read your own writes, and so can everybody else. That’s because each vBucket is normally “active” on exactly one node in the cluster, and by default all clients talk to that one node when accessing the vBucket. The vBucket may be replicated on other nodes, and you can go out of your way to read from a replica if you want, but of course then you might not see the latest data.

The Query Service (for N1QL queries) is a bit different since it relies on an index that runs behind, but you can specify a scan consistency option if your use case depends on querying the most up-to-date data.

That said, anyone evaluating Couchbase should research the benefits and tradeoffs of the overall architecture, particularly the behavior in failover scenarios (where any “active” vBucket instances on the failed node are replaced by promoting replicas on other nodes to “active” status). Specifying durability requirements as @ingenthr mentioned raises the bar for a write to be considered successful, increasing the likelihood of a successful write being visible after a failover.