I'm actually a fan of TiDB and Cockroach. I've met engineers from both, and they're super-sharp.
I am biased towards something like Vitess that builds on top of existing tech. The main advantage is that we can push-down the work to the lowest level, and leverage efficiencies that are already built in MySQL.
But the newer architectures offer better consistency models. Some customers may care more about that.
In the long run, I think these trade-offs should converge.
Overall, any NewSQL is a better alternative than using traditional key-value stores, because it gives you better functionality while not giving up on scalability.
Hey! I really enjoyed the talk you gave at Square :p
I agree that we can't build on the same base forever, but I also think it's really hard to get companies to trust completely unproven solutions -- ground-up rearchitectures like TiDB and Cockroach -- with their data. I'm not sure that there's an easy way to get around that.
Re: consistency -- wouldn't it be possible to e.g. make Vitess work nicely with MySQL's Paxos-based group replication?
MySQL group replication has some issues: It can fail your commits if multiple masters have conflicting transactions, which is a problem for cross-shard distributed transactions. Additionally, group replication is too chatty and doesn't work well cross-dc.
I'm actually a fan of TiDB and Cockroach. I've met engineers from both, and they're super-sharp.
I am biased towards something like Vitess that builds on top of existing tech. The main advantage is that we can push-down the work to the lowest level, and leverage efficiencies that are already built in MySQL.
But the newer architectures offer better consistency models. Some customers may care more about that.
In the long run, I think these trade-offs should converge. Overall, any NewSQL is a better alternative than using traditional key-value stores, because it gives you better functionality while not giving up on scalability.