[packetbeats]

Fantastic in depth article. In my opinion, the tests he perform show not so much drawbacks of the tested systems, but more the fact that defining them in terms of the CAP theorem can be misleading. For example, a CP system should, in case of a partition, wait until the partition is resolved, potentially forever. This is not useful in practice, where almost always some timeout is used. This is why, if I'm interpreting the results correctly, not even a Postgres running on a single node can claim to be CP.

[aphyr]

a CP system should, in case of a partition, wait until the partition is resolved, potentially forever

Not always. In the presence of up to N/2-1 failures (or alternatively, so long as a connected majority exists), many CP systems can continue to operate fully on some nodes. Other nodes may not be able to service requests, though.

This is not useful in practice, where almost always some timeout is used.

Exactly--if you broaden your time horizons for a request so that messages always arrive, you'll be OK. As far as I can tell, this is NuoDB's approach. On the other hand, it means the database blocks some or all requests, potentially forever. This is essentially unavailability, with the added fun that all those requests might suddenly complete well after the client thinks they failed. When your clients need to hand a response back in a matter of seconds, you need to provide for timeouts--which brings you back to the problem of dropped messages again. :)

Postgres running on a single node can claim to be CP.

The Postgres node proper is (assuming you're using the right transaction isolation level) linearizable. The client and the server, considered together, may not be CP--depends on how you interpret network failures. I don't think there's any real way around this--to the best of my limited knowledge, it's a consequence of the FLP impossibility result.

[zzzcpan]

So, essentially nothing can ever be CP, not even a single node, since browsers and humans will never wait forever for something, correct?

[aphyr]

C is a safety property ("nothing bad happens"), but what you're talking about is (kind of) a liveness property ("something good happens"). Real systems need both, so we have to discuss what to do about making correct progress in the face of failures.

Theoretical CP systems can't just block indefinitely, because the network can delay messages for 1 second longer than you choose to wait. Real-world CP systems can usually assume the network recovers--but it might be days before it does, so they'll need some strategy to handle all the requests in the mean time.

Typically, systems choose to time out or otherwise abort certain requests--exactly which depends on the logical topology of the system. For instance, if the primary node for a given shard of the DB is unreachable from a client, a CP-over-shard system would fail those requests--but not others. A totally CP system like ZK might fail requests in any minority components, but continue to work just fine if a majority component is preserved.

Bottom line: you can build CP systems. The only constraint a CP system has to obey is linearizability: successful operations must appear in the same order on all nodes.