Differences between Strict Serializable and External Consistency

Serializability requires that transactions appear to occur sequentially. Serializability does not require any particular ordering on the serial schedule to which the transaction executions be equivalent to.

Strict serializability requires serializability, but also imposes a condition on the order of the serial schedule to which the transaction execution is equivalent to: a transaction that commits before a different transaction starts must appear to happen first. Suppose A commits before B starts--A must appear to take effect before B. With a single node system this comes for free with serializability, and no one really discusses it in this context. In a distributed system it's very hard. See https://cs.brown.edu/~mph/HerlihyW90/p463-herlihy.pdf.

External consistency is a little different. External consistency requires that a transaction that commits before a different transaction commits must appear to happen first. Suppose A commits before B commits--A must appear to take effect first. See here for a definition of external consistency.

The subtle distinction here is that strict serializability imposes no order on concurrent transactions, whereas external consistency imposes a total order on all transactions. External consistency is therefore a stronger condition in the sense that any externally consistent system is also strictly serializable.

You are right, strict serializability and external consistency are pretty much the same. As far as I understand, the one guarantee with external consistency that is not obvious from strict serializability is that a strong snapshot read will follow strict serializability and will observe all previously committed transactions, even though it does not take a lock.

Strict serializability says that transaction behavior is equivalent to some serial execution, and the serial order of transactions corresponds to real time (i.e. a transaction started after another one finished will be ordered after it). Note that strict serializability (like linearizability) still doesn’t say anything about the relative ordering of concurrent transactions (but, of course, those transaction still need to appear to be “isolated” from each other).

For my understanding, Google's Spanner uses the term external consistency instead of strict serializability because it emphasizes the difference between a system that provides consistency for transactions known to the database to be causally related and systems that don’t try to infer causality and offer stronger guarantees.

I would actually venture to say strict serializability is not very particular in what kind of real-time ordering it demands, as long as there is some real-time (partial) order [warn: needs citation]. Most databases will give you strict serializability with a rather simple notion of real-time ordering which is if A commits before B starts, then A appears before B in the serial order. Erm...doh but regular serializability doesn't even enforce this.

Now if you see the spanner docs, it has a stronger definition of real-time order: if one transaction completes before another transaction starts to commit i.e if A commits before B commits, then A will appear before B in the serial order. This they call "external consistency".

TLDR: Strict serializability is different from external consistency in the way it is commonly defined by database vendors. Spanner has a stronger serializability in this sense.