5 ms·

Surprised they didn't mention Cloud Spanner at all.

• stangles1 5y ago
  To be honest, it never even made it onto our radar, not for any particular reason though :) IIRC, Spanner relies on precise timing to make certain guarantees, which is definitely relevant to our use case. I wonder how its write performance would stack up against Postgres and Bigtable.
  • bbulkow 5y ago
    Why would it matter how they do it under the covers? You see correct transactions. The interesting tech in this space is aws redshift, in my testing a few years ago they dominated in price performance when you used the then new node types.
    • stangles1 5y ago
      >Why would it matter how they do it under the covers? It doesn't really matter, I suppose I just got nerd-sniped recalling the details of Spanner's internals and their (somewhat superficial) relevance to the issues of timekeeping mentioned in the blog post :)
• ntietz 5y ago
  I dug back through our design docs from when we designed this, and we largely chose not to use Cloud Spanner due to unknowns. We were more confident we could predict the read and write performance in BigTable (especially due to the constraints you get when you drop relational features).