Surviving a hackathon as a sponsor without becoming a zombie is no joke. Here's how to keep your team of developers as sane and functional as possible.
Some months ago I started work on a way to test random, valid SQL in CockroachDB. This is important to expose unintended behavior in our server.
Running CockroachDB on Kubernetes pairs its built-in replication and survivability with Kubernetes’ process management, creating a highly available system.
We recently improved our distributed SQL performance by implementing column families in CockroachDB. Column families are commonly found in NoSQL databases.
We recently began looking into what it would take to run CockroachDB on a Raspberry Pi, one of the go-to tools of the modern day computer tinkerer.
Our approach to building CockroachDB has been to focus on correctness, then performance, then stability. Without stability, we don’t have a working database
This blog post outlines how fuzz testing uncovered a Schrodinbug in CockroachDB, how Go was partly to blame, and how we addressed it using strong typing.
It’s with great excitement that we announce the CockroachDB Community Forum, a place to find answers, ask questions, and help out fellow CockroachDB users.
The good news is that CockroachDB’s JOIN seems to work, as in, “it returns correct results.” However, this is just our first, unoptimimized implementation.
If we abandoned our earthly constraints, how could we improve consensus algorithms? Specifically, what would it take to make them faster?