* There is a native SQL interface in Spanner, rather than relying on a separate upper-layer SQL layer, a la F1 
* Spanner is no longer on top of Bigtable! Instead, the storage engine seems to be a heavily modified Bigtable with a column-oriented file format
* Data is resharded frequently and concurrently with other operations -- the shard layout is abstracted away from the query plan using the "distributed union" operator
* Possible explanation for why Spanner doesn't support SQL DML writes: writes are required to be the last step of a transaction, and there is currently no support for reading uncommitted writes (this is in contrast to F1, which does support DML)
* Spanner supports full-text search (!)
My understanding from 2012 paper was that it doesn't support nested transactions, even at the storage layer.
Can anybody provide insider-knowledge if it was even a requested feature from Google devs internally?
> Overcoming this limitation requires supporting reading the uncommitted results within an active transaction. While we have seen comparatively little demand for this feature internally, supporting such semantics improves compatibility with other SQL systems and their ecosystems and is on our long-term radar.
No internal demand, but on "long-term radar".