Small Datum

Open and closed source scale-out DBMS that are compatible with MySQL and Postgres have emerged on the market. This is great for the community but there will be much confusion about the meaning of compatible .  This post has yet to have anything on the cloud vendors in China. They are doing impressive work but I don't know enough about it. I am happy to update this post when I learn more. But first, the MySQL and Postgres teams. Team MySQL includes PlanetScale (Vitess), PingCAP (TiDB), Amazon (Aurora), MariaDB ( Xpand ),  SingleStore ,  ClickHouse  and Dolt . Team Postgres includes CockroachDB , Yugabyte , Google (Spanner), Amazon ( Aurora & Redshift ), Microsoft ( CitusDB ),  TimescaleDB ,  CrateDB , YellowBrick ,  Greenplum  and Materialize . It wouldn't be fair to exclude MongoDB, so Team MongoDB is MongoDB, Amazon ( DocumentDB ) and Microsoft (Cosmos DB API for MongoDB ). But the rest of the post is about MySQL and PG. One way to describe compatibility is via three

There are at least three ways to do compression for InnoDB - classic, holepunch and outsource.  The classic approach ( table compression ) was used and enhanced by the FB MySQL team . It might not have been widely used elsewhere. While it works, even for read/write workloads, the implementation is complicated and it isn't clear that it has a bright future. The holepunch approach ( page compression ) is much simpler than the classic approach. Alas, I am skeptical that a filesystem will be happy tracking the metadata from doing a holepunch for every (or most) pages written. I am also skeptical that unlink() response times of seconds to minutes (because of the holepunch usage) will be good for a production DBMS. I wrote a few posts about my experience with the holepunch approach: here , here , here and here . The outsource approach is the most simple from the perspective of InnoDB - let the filesystem or storage do the compression for you. In this case InnoDB continues to do filesyst