I found the front page nearly offensive in its claims:
CockroachDB allows you to deploy applications with the strongest disaster recovery story in the industry.
What?? It’s Alpha.
Customers in Berlin are happier accessing their data from a datacenter in Geneva than Silicon Valley. CockroachDB replicates data within or across continents and flexibly reconfigures to allow access from the lowest latency sources without sacrificing consistency. Say goodbye to eventually consistent solutions and the word maybe.
You’ve got to prove it first! On top of that, this paragraph seems to entirely ignore the existence of CAP. Also, what will the operational overhead of that look like?
Strong consistency is very nice sounding, but it also has a cost associated with it and not the end-all-be-all solution to distributed systems. I think it’s good to have a CockroachDB out there, unfortunately I have seen significantly more hype out of the authors than actual results.
These folks understand CAP. A cockroach range is just a raft group. If you have DC’s across the world, it may make sense to put N/2+1 of the replicas in the DC closest to the user, and the rest in different parts of the world. This way you generally get fast transactions as well as geographic redundancy.
The actual isolation level is NOT full linearizability - it’s serializable snapshot isolation. If you want to learn about some of the ideas that have influenced some of the design choices, check out:
(Can’t find PDF of an important one, but here is the paywall and the presentation)
I’m aware of the research, but that isn’t my point. My point is that the public facing portion of CockroachDB is does not pay tribute to how hard and complicated of a problem all of this is. It completely hides that all of this comes with trade-offs, it doesn’t just solve every problem anyone has ever had magically. As a result, I think the organisation is doing a disservice to the people that are actually most likely to use it, at least in the beginning, because those are the people that understand this is a sophisticated issue.
What do you put in your marketing material? This is not a design specification, and it serves a very different purpose as well as a much larger audience. I think when your infrastructure is chosen based solely on this kind of material you have more serious issues ahead of you. People who understand this issue also don’t put important non-recomputable data into anything less than 5 years old and already proven (sometimes by them) at scale. That said, I think a database with these characteristics actually can serve a majority of existing use-cases, so I’m hoping to use it pretty extensively sometime down the line.
I’ve been impressed with the recent commit activity for cockroachdb. After FoundationDB got taken out by Apple, it’s clear there’s a need for an open source database with solid distributed transactions. The fact that it’s in Go makes this even better: easier to read the code and possibly extend it at the code-level using Go interfaces, without modifying one line of their code. Hope they host some technical talks as well.
Yes, this is exciting! It’s hard to know how big it’ll be, but it’s got a lot of potential.
I’m curious to know why someone has flagged this as “spam”?