And
How long before Google drop it/move on to the next great thing. I would be wary of its use as a key component in my "global, relational-capable database".
When companies started to build applications at web scale and needed services to scale to millions of requests across the globe, it quickly became apparent that relational databases just didn't work well enough. So companies like Amazon and Google built their own that could service these requests but without all the features …
"and you believe they are going to drop it. By the way, do you also think that Google is going to drop Coogle Cloud Platform or Google Kubernetes Engine."
If it suited them. Customer impact has never previously been a concern. And unlike say Azure Stack, you cant run much of it in house if you ever need to.
"Just don't forget the cost of that Spanner cluster! "
Well if you do want to use Spyware as a Service cloud then the good news is that hardly anyone else is, and they are hiring hoards of increasing desperate sales staff to try and flog this stuff in the face of a complete wipeout from Azure and to a lesser degree AWS - so they are pratically giving it away!
… is that they're based on relational algebra and thus have a solid mathematical foundation. Removing redundancy via normalisation gives the reliability and flexibility of predicate logic. JOINs themselves are an artefact of SQL, which is itself is not relational – there is no room in relational algebra for NULL – and gets a lot of things wrong as a result. Modern relational databases can provide incredible performance (things like Swarm64 are aiming for 30 m rows/s @ 40 byte writing) which should be sufficient for most transactional workloads but this requires local clients. Worldwide replication will inherently introduce some latency. Chances are, however, that if you're hitting those kind of limits you already know these things. Unless you're doing NoSQL because "webscale" and wondering why your data keeps getting corrupt or deleted.
The use of a dedicated network with synchronisation via atomic clocks is useful in its own right and possibly the most important aspect of the implementation.
Spanner is an interesting data store. It works great where you have billions of things and each of those things has some small varying number of other things related to it - this is the nested tables trick. Parent and nested child tables are stored together so there's no I/O seek penalty for getting them all together. For other cases it's not relational even though a flimsy SQL interpreter makes it look like it is. Updates are transactional with a compare & set type of operation, which can be done in MySQL too.
The real question is if you trust Google. My experience is that recoverable glitches happen several times a day, momentary failures happen almost every day, and there's some significant screw-up outage at least once a month. Google believes they're perfect so Spanner comes with absolutely no monitoring dashboard.
In my test between Google's hosted Spanner and Google's hosted MySQL 2, Spanner won by an enormous margin. Their MySQL 2 instances always seems to be abnormally slow so it's a biased test. I'd never host data on Google unless there was a real need for it.