What Is the Open Source Alternative to CockroachDB? | Hacker News Reader

What Is the Open Source Alternative to CockroachDB?

medium.com

10 pointsmagden6 comments

Open articleView on HN

Wasn’t CockroachDB open source, right up until it wasn’t?

I think a better question is perhaps “what alternatives are there that are not owned by VC backed corporations?”

This is a good question

A pretty good article and I am looking at Yugabyte more seriously (again).

But I still have questions:

1. Is CockroachDB actually faster (generally) than Yugabyte? Their (own) benchmarks seem to show it is.

2. If true, why? Did writing their own pgsql-compat interpreter really make that much of a difference?

3. This is the big one for me: why does Yugabyte have such large percentages of code in its Github repo in different languages, especially Java, JS and TS? I expect to see a small amount of scripting languages like Python for building or testing or whatever, but it appears that around 30% of the code is actually Java, for a server that was built on top of pure Postgresql. (I'm not a fan of Java in general, except for Elixir.)

Other than those questions, Yugabyte looks like a pretty good migration target and their licensing approach is refreshing.

1. Nope, I don't think that CRDB is generally faster than Yugabyte. Vendors can't say otherwise in their own benchmarks :)

3. That code must be the tooling around the db and various smart drivers (that extend default drivers of Postgres for various programming languages). Overall, the core database engine of Yugabyte is written in C.

1. Of course you are right :)

3. Thank you! It just seemed quite curious (and I don't want a JRE!)

1. Regarding performance, I recently did a simple test. CockroachDB uses a considerable number of CPU instructions compared to YugabyteDB: https://dev.to/yugabyte/comparing-sql-engines-by-cpu-instruc...

Writing a database from scratch is not easy. YugabyteDB uses some PostgreSQL, Kudu, and RocksDB code that has been heavily optimized before. Those are good codebases, and only some parts need to be enhanced to make them distributed.

2. Their Go version of RocksDB, Peeble, seems less efficient. They did it for a good reason. They didn't have the C++ skills to enhance RocksDB itself.

3. The repo holds more than the database.

C: is the SQL layer, based on PostgreSQL

C++: the transactional distributed storage, heavily modified Kudu and RocksDB

Java: some regression tests, the managed service automation, sample applications

TS: the Graphical User Interface

Python: some tooling to build the releases, some support tools

The database itself is C and C++

Reply on news.ycombinator.com