It might also be worth pointing out that 'node' does not reference underlying server.
In a PG or similar architecture, node might be used to specify how many "nodes" are in a replicated setup for high availability purposes.
In Spanner, "Node" is a measure of compute capacity (as is the finer-grain processing units) allowing you to scale up/down without impacting an application's workload.
All instances get high availability regardless of number of nodes or processing units, and the specifics of this are handled by the configuration.
That may have been true at one point, but now you can use Spanner closer to $60-70 a month factoring in storage (and even cheaper with committed use discounts) after upgrading from the free trial instance. https://cloud.google.com/blog/products/databases/use-spanner...
This is the next iteration to make Cloud Spanner more accessible for developers to start using a scalable relational database that values consistency AND availability.
If anyone wants to try out Spanner without cost, this is a great option. There's also a pretty cool starting experience in terms of in-console tutorial to set up a sample app on Spanner.
I'd love to get feedback on getting started with Spanner.
Disclaimer: as my username suggest, I work at Google, quite closely with the Cloud Spanner team.
In a PG or similar architecture, node might be used to specify how many "nodes" are in a replicated setup for high availability purposes.
In Spanner, "Node" is a measure of compute capacity (as is the finer-grain processing units) allowing you to scale up/down without impacting an application's workload.
All instances get high availability regardless of number of nodes or processing units, and the specifics of this are handled by the configuration.