CAP in the Wild

The databases in this book largely occupy one corner or another of the CAP trade-off triangle. Redis, PostgreSQL, and Neo4J are consistent and available (CA); they don’t distribute data and so partitioning is not an issue (though arguably, CAP doesn’t make much sense in non-distributed systems). MongoDB and HBase are generally consistent and partition tolerant (CP). In the event of a network partition, they can become unable to respond to certain types of queries (for example, in a Mongo replica set you flag slaveok to false for reads). In practice, hardware failure is handled gracefully—other still-networked nodes can cover for the downed server—but strictly speaking, in the CAP theorem sense, they are unavailable. Finally, CouchDB is available and partition tolerant (AP). Even though two or more CouchDB servers can replicate data between them, CouchDB doesn’t guarantee consistency between any two servers.

It’s worth noting that most of these databases can be configured to change CAP type (Mongo can be CA, CouchDB can be CP), but here we’ve noted their default or common behaviors.