Spanner is related to MySQL at Google: a product with Spanner's semantics was required to replace MySQL for some important business operations (https://landing.google.com/sre/book/chapters/communication-a...)

it's actually hard to beat MySQL for a lot of things. i was skeptical about this when I joined google, but as an SRE on the MySQL team around this time, I gained a lot of respect for it.

That is an interesting way to look at it; I have wrestled with MDB[1] while working at Google, it was a ginormous MySQL database (possibly one of the world's largest). And I would characterize Spanner's relationship this way, "If you think you are actually going to build an ACID database that scales, then make sure you can support the MySQL api that MDB uses and we'll see just how well it scales."

I don't know if anyone put it to them that way but as Spanner was just getting started when I left I know that one of its success criteria was to be able to be a scalable replacement for MDB. Given the white paper and other papers on their results, I'm sure it managed that requirement.

[1] MDB, Machine Data Base, used throughout the org but especially in Platforms and SRE to keep track of machines and their parts.

I don't know why you think MDB is ginormous by MySQL standards; it was actually quite modest.

Everything you need to know is here: https://research.google.com/pubs/pub38125.html

it walks through the architecture of the Ads DB, the issues with replacing MySQL, and some of the heroic efforts to implement it via Spanner.

At the time, I asked the team why they used MySQL instead of Postgres (which I prefer) and the short answer was: MySQL replication worked at the time.