Some of the raft failure modes for CockroachDB suck to recover from. In testing I've had better results with Yugabyte. If licensing is such a big deal though, CockroachDB loses over Dgraph and Yugabyte.

I doubt anyone will really do anything worth-while in maintaining CockroachDB when it's latest version eventually does falls into Apache licensing.

Clock sync issues also sucked, we had a recurring issue which would cause the cluster to become unstable due to clock syncs and support would throw it in the to hard basket.

Context: https://news.ycombinator.com/item?id=41258843

@bcantril,

Although it sounds like migrating to another DB is not a good choice for Oxide _today_, why didn't you start with yugabyte db? If you were starting from scratch today, which one would you choose for your situation?

There were several factors moving us away from YugabyteDB, not least some worrisome Jepsen results.[0]

[0] https://jepsen.io/analyses/yugabyte-db-1.3.1

Following up on this...

@bcantril, what were your initial reasons for choosing CockroachDB?

We outlined that in detail in RFD 110.[0]

[0] https://rfd.shared.oxide.computer/rfd/0110

I don’t mind paying for software but… for a business with 10mm annual revenue the idea is that for them it’s cheaper to use the best database vs hire an employee to manage a worse one.

So for us solo devs it seems nightmarish. But I think at the enterprise level they say: “hire 2 employees to manage X or buy cockroach”. So they buy if software cheaper.

That’s why it’s so expensive I think.

Note: never worked in corporate so I don’t know.

The related podcast episode has an extended discussion of past experience pushing postgres beyond its original design. Despite working with Bryan and dap at Joyent post Samsung acquisition, I had no idea about much of this.

https://overcast.fm/+AA4jBHynCD8