Isn't this just 4 many-to-many tables and querying using joins, not a graph database?
My interpretation is that they are arguing that they would have to sacrifice the ability to fully model all connections in the system or answer any kind of query (they talk about doing some things “per-user”) because they would have scalability issues or would have to do manual sharding of data. They are considering the full model with all connections as a “graph database”. This terminology is confusing and seems to ascribe extra capabilities to Cloud Spanner.
The intention wasn't to hold out Spanner as a purpose-built graph database, but rather to talk about using it for a graph-y database use case. Will put together a follow-up with some more information, but in summary: * yeah, no built-ins other than relational SQL for graphs * the key thing that make this work are the ability to easily construct global indexes that aren't sharded by the primary key and reasonably fast joins between them * it's also helpful that Spanner does a reasonable job of parallelizing queries (e.g. a lot of times we'll get a 15x increase in speed vs. a sequential plan) * we then do the fan-out across the graph in our Java client