3 ms·

Cockroach Labs scores $160M Series E on $2B valuation

5 points by derekperkins 6y ago

derekperkins 6y ago
I don't really understand the continuing appeal for CockroachDB. Yes there is some cool tech, but given that all transactions are synchronously distributed, there's a hard cap on how fast it can be. I have yet to see any significant case studies about real workloads, while their competitors like Vitess are seeing whole-scale adoption from their users - including Slack and HubSpot.
- vvern 6y ago
  I'm not sure I understand this. Vitess performs synchronous replication to at least two nodes for all write IIUC. The point that I think you're making is that Vitess generally does that in a single region so, for a given write, you see single-region latency. Cockroach can do this too. In fact, in very similar terms. Cockroach allows data to be partitioned and then partitions can be configured with placement constraints, including which regions to place the data. At the end of the day, for queries which touch the equivalent of one shard, you can configure cockroach to experience a latency profile comparable to Vitess. Additionally, cockroach offers the ability to survive regional failures, and, likely most importantly, it allows you to perform arbitrary, serializable cross-shard transactions. Vitess has some sort of 2PL transaction thing but last time I heard Sugu talk about it, he said something like, nobody uses it.
  - derekperkins 6y ago
    Since I'm not a Cockroach expert, I'm sure that there are ways to configure it that eliminate some of those latency issues that were common early on. Both Vitess & Cockroach can replicate across regions and survive regional failures. As for cross-shard transactions, that's mainly what I'm referring to about slowness. Vitess does have 2PC, but as you mention, almost nobody uses it in production. Companies using Vitess architect their data and sharding patterns so that cross-shard transactions aren't necessary. There are definitely cases where that is part of the requirement, but in far fewer cases than many people think. At the end of the day, I'm still waiting to see any major tech company push serious workloads onto Cockroach. Until that happens at scale, and as I continue to see more and more of those major companies adopting Vitess, it's going to be hard to convince me that Cockroach solves all the problems that they claim to. What they are fantastic at is great docs and beautiful interfaces, both of which are lacking on the Vitess side. :)
    - vvern 6y ago
      > At the end of the day, I'm still waiting to see any major tech company push serious workloads onto Cockroach. Until that happens at scale, and as I continue to see more and more of those major companies adopting Vitess, it's going to be hard to convince me that Cockroach solves all the problems that they claim to. What they are fantastic at is great docs and beautiful interfaces, both of which are lacking on the Vitess side. :) Fair enough, keep your ears open and you'll hear more. Vitess's distribution model is simpler, less tightly coupled and in that way more easily scalable. It indeed has, at this point, been deployed at scales cockroach has not yet reached. Does your main complaint boil down to the ability of Vitess to do async cross region replication? If so, sure, crdb will have higher commit latency. This use case comes up but it's not common. The general solution when that matters is to leverage nearby regions. > As for cross-shard transactions, that's mainly what I'm referring to about slowness. This has gotten better, but it doesn't get around the speed of light. We've got some ideas we're playing with to offer an increasingly flexible models which expose better tradeoffs here. > Companies using Vitess architect their data and sharding patterns so that cross-shard transactions aren't necessary. There are definitely cases where that is part of the requirement, but in far fewer cases than many people think. I think this is really the point of contention. Vitess enables applications that require thousands of database machines to operate at the cost of careful application architecture decision making. If you're running thousands of database VMs you're definitely spending a lot on engineering. Those companies exist, sure, but it's not most of the Fortune 500. I do definitely agree that something like Vitess is superior to the Cassandra-like NoSQL database I used to work with. You can build correct applications with those (and something like Kafka), but it's hard. Planning out your application and know how to shard it up-front is hard too. Vitess is amazing for people using MySQL and then realizing they need to scale, but then you do need to go change things and drop the transactions. Anyway, I think on the whole, you're saying very fair things. Vitess leverages a mature database in a nice way. If you've got the scale where you need 10s of thousands of cores, it's a better than any NoSQL database out there. It just does have up-front costs to the application developer. CRDB is selling the gospel of the distributed transaction. The pitch is that once you get used to the application development power of having it, you won't want to go back. The argument is that the tradeoffs that it offers to provide that are reasonable for global applications that need to operate at the scales of thousands of cores for the database which is more than most OLTP business applications need. Both the scale and set of tradeoffs will get better over time.

5 points by derekperkins 6y ago

I don't really understand the continuing appeal for CockroachDB. Yes there is some cool tech, but given that all transactions are synchronously distributed, there's a hard cap on how fast it can be. I have yet to see any significant case studies about real workloads, while their competitors like Vitess are seeing whole-scale adoption from their users - including Slack and HubSpot.

vvern 6y ago
I'm not sure I understand this. Vitess performs synchronous replication to at least two nodes for all write IIUC. The point that I think you're making is that Vitess generally does that in a single region so, for a given write, you see single-region latency. Cockroach can do this too. In fact, in very similar terms. Cockroach allows data to be partitioned and then partitions can be configured with placement constraints, including which regions to place the data. At the end of the day, for queries which touch the equivalent of one shard, you can configure cockroach to experience a latency profile comparable to Vitess. Additionally, cockroach offers the ability to survive regional failures, and, likely most importantly, it allows you to perform arbitrary, serializable cross-shard transactions. Vitess has some sort of 2PL transaction thing but last time I heard Sugu talk about it, he said something like, nobody uses it.
- derekperkins 6y ago
  Since I'm not a Cockroach expert, I'm sure that there are ways to configure it that eliminate some of those latency issues that were common early on. Both Vitess & Cockroach can replicate across regions and survive regional failures. As for cross-shard transactions, that's mainly what I'm referring to about slowness. Vitess does have 2PC, but as you mention, almost nobody uses it in production. Companies using Vitess architect their data and sharding patterns so that cross-shard transactions aren't necessary. There are definitely cases where that is part of the requirement, but in far fewer cases than many people think. At the end of the day, I'm still waiting to see any major tech company push serious workloads onto Cockroach. Until that happens at scale, and as I continue to see more and more of those major companies adopting Vitess, it's going to be hard to convince me that Cockroach solves all the problems that they claim to. What they are fantastic at is great docs and beautiful interfaces, both of which are lacking on the Vitess side. :)
  - vvern 6y ago
    > At the end of the day, I'm still waiting to see any major tech company push serious workloads onto Cockroach. Until that happens at scale, and as I continue to see more and more of those major companies adopting Vitess, it's going to be hard to convince me that Cockroach solves all the problems that they claim to. What they are fantastic at is great docs and beautiful interfaces, both of which are lacking on the Vitess side. :) Fair enough, keep your ears open and you'll hear more. Vitess's distribution model is simpler, less tightly coupled and in that way more easily scalable. It indeed has, at this point, been deployed at scales cockroach has not yet reached. Does your main complaint boil down to the ability of Vitess to do async cross region replication? If so, sure, crdb will have higher commit latency. This use case comes up but it's not common. The general solution when that matters is to leverage nearby regions. > As for cross-shard transactions, that's mainly what I'm referring to about slowness. This has gotten better, but it doesn't get around the speed of light. We've got some ideas we're playing with to offer an increasingly flexible models which expose better tradeoffs here. > Companies using Vitess architect their data and sharding patterns so that cross-shard transactions aren't necessary. There are definitely cases where that is part of the requirement, but in far fewer cases than many people think. I think this is really the point of contention. Vitess enables applications that require thousands of database machines to operate at the cost of careful application architecture decision making. If you're running thousands of database VMs you're definitely spending a lot on engineering. Those companies exist, sure, but it's not most of the Fortune 500. I do definitely agree that something like Vitess is superior to the Cassandra-like NoSQL database I used to work with. You can build correct applications with those (and something like Kafka), but it's hard. Planning out your application and know how to shard it up-front is hard too. Vitess is amazing for people using MySQL and then realizing they need to scale, but then you do need to go change things and drop the transactions. Anyway, I think on the whole, you're saying very fair things. Vitess leverages a mature database in a nice way. If you've got the scale where you need 10s of thousands of cores, it's a better than any NoSQL database out there. It just does have up-front costs to the application developer. CRDB is selling the gospel of the distributed transaction. The pitch is that once you get used to the application development power of having it, you won't want to go back. The argument is that the tradeoffs that it offers to provide that are reasonable for global applications that need to operate at the scales of thousands of cores for the database which is more than most OLTP business applications need. Both the scale and set of tradeoffs will get better over time.