vitess VS tidb

With Vitess likely merging a lot of its binaries into a single unified binary: https://github.com/vitessio/vitess/issues/7471#issuecomment-...

... it would be a wild future if Vitess replaced the underlying MySQL engine with this as long as the performance is good enough.

Thank you for the compliment!

We recently started adding support for CTEs in Vitess! You can check out https://github.com/vitessio/vitess/pull/14321 if you want to see some technical details of the implementation.

For now, we have added preliminary support by converting them to derived tables internally, but we believe that we need to make CTEs first-class citizens themselves of query planning. Once we make that change, we can look towards supporting recursive CTEs.

This however will take some time, but then, all good things do!

Why would it be a Google project? https://github.com/vitessio/vitess

This is great news. I strolled around https://github.com/vitessio/vitess/issues/12967.

Are there any public discussions of more trade-offs vitess has to make to enable fks?

MySQL + Vitess I noticed Slack gets by using MySQL because they're using Vites. From Slack's post (https://slack.engineering/scaling-datastores-at-slack-with-vitess/) it seems like they choose Vites because it facilitated a smooth transition because it's built on top of MySQL.

This sounds very similar to the connection pooling done by vitess https://vitess.io/.

https://github.com/vitessio/vitess/issues/12967

A lot of this is possible thanks to the magic of Vitess.

"Vitess is a database clustering system for horizontal scaling of MySQL."

https://github.com/vitessio/vitess

tidb has been around for a while, it is distributed, written in Go and Rust, and MySQL compatible. https://github.com/pingcap/tidb

Somewhat relatedly, StarRocks is also MySQL compatible, written in Java and C++, but it's tackling OLAP use-cases. https://github.com/StarRocks/starrocks

It's MySQL-Compatible database for scale and real-time analytics https://github.com/pingcap/tidb

PingCAP | https://www.pingcap.com | Database Engineer, Product Manager, Developer Advocate and more | Remote in California | Full-time

We work on a MySQL compatible distributed database called TiDB https://github.com/pingcap/tidb/ and key-value store called TiKV.

TiDB is written in Go and TiKV is written in Rust.

More roles and locations are available on https://www.pingcap.com/careers/

Pesquise por CockroachDB ou TiDB

OLTP usually comes with high throughput of transactions, which means usually write(e.g., IUD - insert, update, delete) to read (e.g., select) ratio is above 4 or 5 or even higher. There are some good benchmarks to test OLTP workload like TPC-C (https://www.tpc.org/tpcc/), and some benchmarks to test OLAP workload like TPC-H (https://www.tpc.org/tpch/). For mixed or hybrid OLTP and OLAP (it's called HTAP, see this blog for some background https://en.pingcap.com/blog/the-beauty-of-htap-tidb-and-allo...), TPC-H was originally designed for this, however, it actually doesn't reveal the real world workload with several drawbacks. A newer research work from UC Berkeley proposed a HTAP benchmark called TAOBench (https://www.vldb.org/pvldb/vol15/p1965-cheng.pdf) which is pretty interesting and worthy to check.

For the HTAP systems, as mentioned in the above blog, there are quite a few industrial products, like Google just announced AlloyDB (https://cloud.google.com/alloydb), Snowflake's UniStore (https://www.snowflake.com/workloads/unistore/), and one of the most popular open source projects TiDB (https://github.com/pingcap/tidb) which have been deployed by many business applications.

Hopefully these may help a little bit :-)