Yugabyte's company blog covers its distributed SQL database, including Raft, RocksDB, benchmarks against rivals and PostgreSQL topics.
HN commenters use it for database comparisons and architecture explanations, such as the DocDB design on RocksDB and the Postgres timestamp guide.
Looks like you cross-posted this comment here and on my blog, so I'll also cross-post in my response.
I am quite confused by your statement that YugaByte does not claim linearizability. The C of CAP is linearizability (see the original CAP theorem https://users.ece.cmu.edu/~adrian/731-sp04/readings/GL-cap.pdf). By claiming to be CP from CAP, you are claiming linearizability.
CockroachDB also makes the same CP claim. However, they explicitly walk back from this claim (https://www.cockroachlabs.com/blog/living-without-atomic-clocks/). In contrast, YugaByte documentation makes no effort to walk back from this claim. Rather, the documentation seems to indicate that YugaByte is linearizable at: https://blog.yugabyte.com/jepsen-testing-on-yugabyte-db-database/ and https://docs.yugabyte.com/latest/develop/learn/acid-transactions/.
Also, I would encourage you to read the Herlihy-Wing paper on linearizability published in 1990. You seem to be confusing linearizability with ACID isolation levels, which are actually a different concept. Peter Bailis has a good blog post on the difference: http://www.bailis.org/blog/linearizability-versus-serializability/.
On your third point, we agree. However, the point of my post is that relying on max clock skew without hardware support is dangerous. I’m going so far as to say that it’s so dangerous that it is incorrect to claim consistency guarantees when you make such assumptions.
I would really encourage YugaByte to consider using global…
There's a feature matrix here [1] comparing YugaByte to CRDB, TiDB, Aurora, CosmosDB, Spanner, MongoDB, FoundationDB, Cassandra and Dynamo. No idea about performance characteristics though.
[1] https://docs.yugabyte.com/latest/comparisons/
edit: there is a relatively recent blogpost comparing the two here: https://blog.yugabyte.com/yugabyte-db-vs-cockroachdb-performance-benchmarks-for-internet-scale-transactional-workloads/
Key summary from the post:
In a nutshell, YugaByte DB delivers an average of 3.5x higher throughput and 3x lower latency compared to CockroachDB. Following are the detailed performance characteristics at scale (millions of rows) for internet-scale transactional workloads:
5x more insert throughput, 9x faster
4x more query throughput, 3x faster
4x more distributed transactions throughput
In addition, YugaByte DB offers additional features such as read replicas (for timeline-consistent, low-latency reads from the local region) and automatic data expiry (by setting a TTL at table level or row level).
Obviously to be taken with a grain of salt as with all benchmarks doing head-to-head comparisons.
Afaik, Postgres flavored Aurora has a single master for writes and doesn't allow horizontally scaling writes[1]. I believe reads can scale by bringing up multiple read replicas. Cockroach DB is "distributed SQL" so writes are also scaled across multiple nodes.
You can see some details about how this affects write perf in this blog by another distributed SQL database which compares the three databases (YugabyteDB, Aurora and CockroachDB) - https://blog.yugabyte.com/comparing-distributed-sql-performance-yugabyte-db-vs-amazon-aurora-postgresql-vs-cockroachdb/
[1] There is also multi-master Aurora (but based on https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-multi-master.html#aurora-multi-master-architecture that only supports 2 read-write masters and has other limitations).
Hi @catblast,
(I am the CTO of Yugabyte) Your points are all completely valid. Just wanted to add my 2 cents.
With YugabyteDB specifically, we are more than just PostgreSQL wire-compatible, we "reuse" the upper half of PostgreSQL to support almost all PG features (examples: stored procedures, triggers, partial functions, etc). So the aim is to build something that has "almost all PG features" while being able to "run cloud-native - with HA, scale and geo-distribution" - our hope is that this allows YugabyteDB to really become a viable option instead of PostgreSQL when apps are being built for the cloud. Here is a blog post on the benefits we realized reusing PostgreSQL: https://blog.yugabyte.com/why-we-built-yugabytedb-by-reusing-the-postgresql-query-layer/
YugaByte DB product manager here. we have compared the Spanner and Calvin architectures in depth previously (https://blog.yugabyte.com/google-spanner-vs-calvin-global-consistency-at-scale/). one key difference comes from the fact that Calvin’s deterministic locking protocol requires advance knowledge of all transactions’ read/write sets before transaction execution can begin -- this leads to repeated transaction restarts if the secondary index is on a column whose value is changing frequently as well as no support for client-initiated sessions transactions. in other words, Calvin is better suited for a transactional NoSQL database as opposed to a true distributed SQL database.
Yugabyte uses actual Postgres code for the query layer, on top of data persistence (distribution/replication) handled by DocDB document store, which itself is a layer on top of RocksDB: https://blog.yugabyte.com/how-we-built-a-high-performance-document-store-on-rocksdb/
CockroachDB (aka CRDB) is completely custom and compatible with Postgres wire/datatype protocols, which operates directly on its own key/value store called Pebble (but originally was also RocksDB): https://www.cockroachlabs.com/blog/distributed-sql-key-value-store/
Both systems are foundationally the same SQL-on-KV but implement it very differently.