Early NoSQL databases were designed in the shadow of the CAP theorem. We were told to "pick 2 out of 3--you can't have it all." Well, maybe you can't have it all, but was throwing out ACID transactions the best way forward? NoSQL innovators Google seem to think no and claim their new distributed database Spanner is both consistent and highly-available. Have they beat CAP? This talk will:
- Examine impact of CAP on early NoSQL systems
- Explore the design space of consistent systems
- Answer the question of what price to we pay for transactions in a distributed system
- Propose a path towards a better NoSQL