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-perform...

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.

Going to vendor's website always have comparisons that claims, it can do everything that the competitor's can not. What I'd also like to know is limitations. Where it's not a good idea to use a product? This would help me make informed decision and build relationship with vendor based on trust.

Best of luck with new licensing.

Thanks for your wishes @nishantvyas!

This might help answer some of your questions: https://docs.yugabyte.com/latest/introduction/#what-are-the-...

Please look at the trade-offs in the above section (vs SQL, vs transactional NoSQL, vs eventually consistent NoSQL).

(founder/cto at YugaByte)

Joins and transactions across nodes, very cool. Inner joins/right joins too? Do these have similar time complexity, latency/bandwidth aside, as a comparably indexed traditional RDBMS?

Yes, we support all types of joins (inner, right included) and indexes. In fact, we recently also enabled stored procedures with plpgsql :)

Tuning to perform these efficiently in a distributed manner is a work in progress (this is wrt the time complexity question). The hints used by a traditional RDBMS would not be effective in the distributed case - optimizing this requires changing the optimizer and doing more "push-downs" to optimize the queries. Currently, depending on the query, these may or may not be fully optimized - but we hope to have good coverage soon!

YugaByte product manager here -- have documented the answer to your question [1] As you can see, there are many similarities but there are also a few important differences such as depth of PostgreSQL compatibility (YB reuses PostgreSQL query layer while CRDB is a re-implementation) and latency/throughput observed for modern OLTP workloads.

[1] https://docs.yugabyte.com/latest/comparisons/cockroachdb/

That comparison misses some things like "AS OF SYSTEM TIME" queries, changefeeds, and other CRDB-specific pieces.

Hi @kodeblah,

True, but note that the comparison only focuses on SQL (as it related to PostgreSQL) features and not any DB-specific features.

The YugaByte DB specific pieces are not included as well - for example, support for YCQL (Cassandra-compatible) and YEDIS (Redis-compatible) APIs to the DB.

(disclosure: founder/cto at yugabyte)

GO-JEK did some performance benchmarking: https://medium.com/yugabyte/go-jeks-performance-benchmarking...

Something related to the benchmark: https://pingcap.com/blog/why-benchmarking-distributed-databa...