This documentation talks about it in brief: https://cloud.google.com/spanner/docs/whitepapers/life-of-reads-and-writes https://cloud.google.com/spanner/docs/whi

This documentation talks about it in brief: https://cloud.google.com/spanner/docs/whitepapers/life-of-reads-and-writes https://cloud.google.com/spanner/docs/whitepapers/life-of-re.... You can read the spanner paper for more detail: https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf https://static.googleusercontent.com/media/research.google.c... The simple answer is that there are round trips required between datacenters when you have a quorum that spans data centers. Additionally, one replica of a split is the leader, and the leader holds write locks. So already you have to talk to the leader replica, even if it's out of the DC you're in. Getting the write lock overlaps with the transaction commit though. So for your example if we say the leader is in Canada and the client is in Australia, and we're doing a write to row 'Foo' without first reading (a so called blind write): Client (Australia) -> Leader (Canada): Take a write write lock on 'Foo' and try to commit transaction Leader -> other replicas: Start commit, timestamp 123 Other replicas -> Leader: Ready for commit Leader waits for majority ready for commit and for timestamp 123 to be before the current truetime interval Leader -> Other replicas: Commit transaction, and in parallel replies to client. Of course there are things you can do to mitigate this depending on your needs, but there's no free lunch. If you have a client in Australia and a client in Canada writing to the same data you're going to pay for round trips for transactions.