(I'm the author of the post - just woke up and saw this discussion. Hi!)
Definitely wasn't meaning this post's title to be clickbait-y. 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
Definitely wasn't meaning this post's title to be clickbait-y. 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