awoods187

PM at CRL here--we love Fly too! Definitely can see our two products working together!

PM@cockroach labs here. Which tools did you experiment with? We've been working to increase our tooling capabilities!

PM @CockroachDB here. Have you seen our performance page? https://www.cockroachlabs.com/docs/dev/performance.html CRDB can easily scale throughput.

At Cockroach Labs we switched to Calver covered in this thread https://news.ycombinator.com/item?id=19658969

This is super cool

Hi- product manager from CRL here. You are right--we hope to demonstrate that CockroachDB is built to scale horizontally. Deployments of CockroachDB can grow by easily adding more nodes to the cluster which in turn linearly scales throughput. We have posted the most recent published Aurora numbers as a comparison to demonstrate how architecture can influence scale.

We also hear your point about efficiency as tpmC (throughput) alone isn't sufficient to compare systems without taking hardware into account. TPC-C asks users to provide a tpmC per dollar amount. We conducted this price comparison previously in this blog post https://www.cockroachlabs.com/blog/cockroachdb-2dot1-perform.... These results are even lower in 19.2 because we can achieve greater tpmC with fewer nodes.

This page wasn't met to be competitive-we simply showed Aurora as a reference point. Since we want to focus on CockroachDB we will remove the Aurora comparison.

The labels are incorrect (we combined the charts in the final draft)--fix incoming. GCP was much worse than AWS on this test.

We can consider expanding this in our testing next year! Glad you found it helpful

All of the benchmarks we used to test are open source.

TPC-C https://www.cockroachlabs.com/docs/stable/performance-benchm... Sysbench https://github.com/akopytov/sysbench Stress-ng https://kernel.ubuntu.com/~cking/stress-ng/ iPerf https://github.com/esnet/iperf PING https://linux.die.net/man/8/ping

I'm the author of the post.

1. Between 90 and 135 16 vCPU nodes depending on cloud hardware 2. The cluster replicates this data three ways across all three nodes (so the cluster actually contains 12+tb of data) ensuring high availability. We intentionally reported the unreplicated number for clarity and comparison to TPC-C spec 3. Our graph is mislabeled. It should read transactions per second `tps`. Nice catch! 4. We can't comment on other database performance as they haven't release any TPC-C numbers.

I'm the author. We've introduced transactional write pipelining (covered in a forthcoming blog post), load-aware rebalancing, and completed general performance tuning which all contribute to our improved performance numbers.

We marked these drivers as beta support to indicate that we haven't tested them to the same rigor as our internally developed features. Basic querying and transactions should work with any of these drivers, but features like introspection and less commonly-used data types haven't been extensively tested across all drivers. Many people report using these drivers in production, however, we've prioritized new feature development for CockroachDB over extensive driver testing. We encourage you to give these drivers a try and let us know if you encounter any issues--we'll be happy to fix any bugs brought to our attention.

Which ORMs are you hoping Cockroach would support?

Hi all--My name is Andy and I'm a PM here at Cockroach labs. We are currently working through partitioning as a key feature of our 1.2 release scheduled for April 2018. Our solution can be found at this RFC (https://github.com/cockroachdb/cockroach/pull/18683). One thing to note, we don't require you to define your partitions up front. We'd love to get your feedback on this feature--please feel free to comment on the RFC or reach out to me directly at andy@cockroachlabs.com.