CockroachDB Skitters into Beta

Plenty useful -- we have SQL-like query tools at work (which operate on SSTables and ColumnIO) that I use extensively nearly everyday and I almost never do a join. Just SELECT and WHERE gets the job done 98% of the time for me.

> This is one of the most exciting DB's coming into the world, and I've had a lot of fun watching progress from the sidelines!

I'm going to have to disagree. The German HyPer DBMS has a lot more interesting ideas. Cockroach is just distributed MVCC from the 1980s on top of a key/value store.

MemSQL also has a new LLVM architecture written by the HipHop VM inventor that they poached from Facebook.

For one, just indices in a strongly consistent distributed store, with ACID, is a big deal. Doing this yourself with another strongly consistent DB is a massive error prone PITA.

Full disclosure: I work for a non-competing (EC vs SC) database - which also has an ugly name "gunDB".

Super excited to hear about CockroachDB's progress - and their decision to add SQL support I think was smart.

However, I can't go without critiquing their marketing of "Scalable" and "Strongly Consistent", especially when they reference horizontal scaling. Strongly Consistent systems bottleneck around a centralized master, or around complex consensus algorithms like PAXOS or Raft. CockroachDB has previously written this off with "we're using Google's Spanner algorithm" but this makes them vulnerable to a Split-Brain failure (which contradicts their other goal of "Survivability"), for anybody interested in this line of research I recommend googling Kyle Kingsbury "Aphyr" "Call Me Maybe" Jepsen Tests. With that said, you can't just toss horizontally "Scalable" and "Strongly Consistent" into the same blog because they are fundamentally at odds with each other - the physics just don't work. To achieve this you only have two options... either (A) vertically scale the Master, or (B) make incredibly technical sharding decisions (where no two pieces of data that depend upon each other can be in separate shards). The first (A) is not the definition of being scalable, because a single machine can only scale so much (limits of the physical system). And (B) cannot be generalized, which would require every company building on top of CockroachDB to either have the expert knowledge of predicting the exact sharding schema in advance (maybe why they are moving to SQL?), or have to depend upon expensive consulting options (perhaps provided by CockroachDB, after a startup has already built itself around using the free open source product?). The third option is that they are over-generalizing their database trade-offs, and that you cannot actually get horizontal "Scalability" and "Strong Consistency".

That said, I know the CockroachDB guys are smart, so I'd love to hear the more nuanced/detailed explanation. I'm just trying to keep your guys' marketing and promises in check with the reality.

It's pretty funny, I'm from California and thought the name was cute, but just told a New Yorker friend about it and she said, "That's disgusting!"

Of course, literally the first time I ever saw a cockroach was when I visited New York a few years ago. I was riding the escalator down to the subway and the cockroach was riding the up escalator next to me! Off to its next great adventure, I'm sure.