couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Alfke <>
Subject Re: Would this be a sane use case for couchdb?
Date Wed, 09 Apr 2014 16:23:43 GMT

On Apr 8, 2014, at 11:45 AM, Der Engel <> wrote:

> The webapp is going to be a invoicing software for certain niche,  so I
> guess I probably need a DB were transactions are reliable and data
> integrity is very good.

CouchDB doesn’t offer transactions, at least not in a traditional sense. While updating
a document is atomic, updating multiple documents is not; essentially each document update
is its own little transaction. (Even if you use the _bulk_docs command.)

If you can accept that, data integrity is great. The append-only file format is almost immune
to corruption, and databases are very easy to back up efficiently (via replication.) The MVCC
feature prevents you from accidentally overwriting the wrong version of a document, or from
doing a read-edit-write cycle that smashes someone else’s intervening write.

The lack of transactions may seem bad, but often it just requires thinking different[ly] about
your data. In a document database you can aggressively *de*normalize by storing multiple small
data items inside a single document, instead of in separate tables — a canonical example
is an address card doc that stores arrays of phone numbers and emails. Such a document will
always be internally consistent. It’s also possible to create a pseudo transaction as a
document that contains a list of the IDs other documents and revisions that are collectively

Anyway, if you do get to clustering with any database, you’ll probably find that you have
to lower your standards about transactions anyway. Clustered databases mostly respond to the
constraints imposed by the CAP Theorem by relaxing Consistency. Those that don’t (by using
shared locks) will instead suffer from lowered Availability or Partition-tolerance.

View raw message