Except that A in CAP has nothing to do with overall system's availability over time and using it as such is just confusing.

But it makes sense in this case. The system guarantees CP. But as customer it looks like you're getting CA as well, because A is so high. If you drink the kool-aid, you get C & A & P.

The kool-aid isn't too bad, though if they can measurably guarantee A > 99.999999%, I'm happy to round off to 100% and call it CAP.

The availability is "only" 99.999%, which IMO is still really high!

(I work for Google Cloud)

https://uptime.is/99.999 puts that at:

Daily: 0.9s

Weekly: 6.0s

Monthly: 26.3s

Yearly: 5m 15.6s

Where does it say that? Does google cloud spanner guarantee three nines uptime?

On the spanner page it says:

>> This feature is not covered by any SLA

;) ;)

Once Cloud Spanner leaves beta, it will be covered by an SLA. GCP Alpha/Beta products don't have SLAs for the most part.

So essentially a marketing buzz. "It's always available because we spent a lot of money to make it available"

CAP is about how the system deals with partitions not whether it has partitions or not.

The person who wrote this "marketing buzz" is Eric Brewer, who was the originator of the CAP theorem in the first place. I think he knows what it was about :)

See my other comment in this thread on how they still used misleading language in their marketing, regardless of who the author is.

Don't fall for these PR tricks. Hiring thought leaders/influencers is one that should be easy to spot. Best to judge claims on their own merit and not by the person that speaks them....

What am I supposed to think about someone who creates a throwaway account called "the_cap_theorem"? You look like a competitor that's freaking out and throwing FUD.

I don't think Eric's words were misleading. People will judge Cloud Spanner on its own merit, but given the reputation Eric has both academically and professionally, I think Cloud Spanner is deserving of attention, and is not a "PR trick".

I don't care who Eric is, it is still misleading. He knows he is providing misinformation and he tries to cover his a__ by adding that technically it is a CP system, when a partition happens. And that's what matters.

Saying it is CA because Google threw some money to reduce chances of a partition happening is very misleading. By that definition you could take any RDBMS and claim that is CA because with enough money you can make sure hardware won't fail. It defeats the purpose what CAP is being used for, which is telling us how the system will behave when partition does happen. It defeats the purpose what Aphyr was doing with his Jepsen tests which observe how given storage solution behave when there's a network partition.

The claim that Eric Brewer wrote regarding Spanner reduces makes him lose him credibility to me at least. It almost feels like he was hired by Google, just so he could claim that.

I think you've somewhere lost the plot of what Google has achieved here, and in no way does it detract from running Spanner against Jepsen.

Google is claiming they've built a geographically distributed CP system with linearizability and 99.999% global availability. They haven't defeated CAP because A is about total availability in the face of network failures. But for most practical purposes they've achieved exactly what most people want in their database. Consistent and mostly available except perhaps 30 seconds a year. That is why it is completely acceptable for Eric to say this is a "effectively" a CA system.

Eric was hired to help BUILD this, not market it.

Aphyr also has no issues with Eric's comments (read Twitter) - Spanner a CP system with better latency due to the use of TrueTime.