Whew. Those years of enduring "SQL is dead" posts were not easy. Now if we can just rebrand "cloud" to "someone else's computer", much will be right with the world.
Point is there are strong and weak consistency models with and without SQL execution engines, and they’re all useful.
Other generic DBMS query protocols could specify their own consistency semantics, but I'm not aware of any that do. (I guess, if you consider REST a "DBMS query protocol", then CouchDB is an example of a DBMS "conforming" to the consistency semantics specified in the REST protocol.)
So a write on that lower-level RPC interface shouldn't, by the SQL spec, be able to cause a sequence of SQL wire messages like this:
BEGIN
SELECT COUNT(*) FROM foo;
-- 100s later
SELECT COUNT(*) FROM foo;
COMMIT;
If it could, under Spanner, then Spanner wouldn't be conformant to [the read-only subset] of whatever SQL standard it claims to obey. But, according to the Cloud Spanner docs (https://cloud.google.com/spanner/docs/transactions#read-only...), the above code will always return the same values for the two queries.
And, if you're feeling argumentative, you could interpret the reason for the particular consistency semantics, as the fact that Cloud Spanner claims to support SQL, and SQL mandates that consistency. You could suppose that, without that claim, Cloud Spanner would never have bothered building a transactional MVCC layer into their architecture.
Spanner had a transactional MVCC system in their original implementation described in the 2012 paper which predates SQL support described in the 2017 paper. Therefore it is probably wrong to credit SQL with Spanner's MVCC system.
That's actually okay, per SQL. Any SQL transaction may fail, for any reason, at the server's discretion. Because the user's permission to operate on the table was revoked in the middle of their transaction, for example. Or because the server is going down and wants to drop connections.
SQL clients have to be written to assume that any transaction could enter a failed state "before" the execution of a statement, even if the previous statement returned a success.
Helpfully, though, they know that 1. by the SQL standard, that failure means that no part of the transaction applied; and 2. that this failure-state is a failure of the transaction context to be valid, rather than a failure of their statement to be valid. (They don't know that their statement is valid, but they know that they haven't been told that it isn't.)
Now if only I didn't have to keep looking up the pandas "Comparison with SQL" page every time I have to do some manipulations to a data frame...
Doesn't change how much I love Elastic.
Sometimes the incumbent needs a kick in the ass. It feels like the pace of improvement in boring old databases has had an uptick for the last five or so years. That feeling of slowness is probably what opened the door in the first place. If you put enough beers in me I would have admitted as much at the time. Database progress got boring.
But the other thing is that people forget the past when it's been too long since the Dark Times. I have my fingers crossed, and perhaps I will regret that naivete some day, but I have my fingers crossed anyway that there's a whole generation of young developers that will know, viscerally, why we use Relational Databases. Why concurrent access to data is hard and we should leave it to the professionals instead of rolling our own every time we're feeling bored at work. The same way we generally let other people do billing, or data viz.
[Edit to add]
One of the biggest things I'm champing at the bit for an opportunity to use is the newer event streaming stuff that builds on exporting the WAL data from ACID databases. My OLTP data set gets to be the system of record as God and Man intended, but there's a perfectly sane mechanism to support the occasionally very valid OLAP-oriented business concerns. Any time a tool can take away something that makes my life difficult or unpredictable is a good tool.
I just haven't been at the right sized company that it's an unsolved problem that we need to solve, and I have higher priorities for my own stuff.
Nothing has changed since. As there exist fundamental limitations preventing all those traditional databases from ever satisfying requirements. And new distributed relational databases designed and built from the ground up so far don't seem to be able to meet neither SQL crowd's expectations nor win people who are facing actual distributed problems. It's like progress in databases doesn't favor familiarity over other things at all, effectively resetting familiarity with relational model altogether and forcing even models to compete with each other for fresh minds.