I have had very bad experiences with graph dbs at scale. To the point where I will never again work on a project based on a graph db. YMMV, but I'm done with them forever.

[edit] To elaborate: tuning read and write performance is difficult, essentially everything must be indexed. This results in an explosion in data size--so data that might be X TB in csv format becomes maybe 10X when you consider all the indexes and bloat from the graph db's storage format. Which brings us to the topic of compression: there isn't any. Moreover, graph dbs are basically all quite immature compared to other db software, they haven't seen the test of production to the same degree, nor have they gotten the same attention in terms of bugfixes, performance tuning, etc. So they often have very sharp edges that you encounter under load. So if you like spending tons of money and time on zero value work, choose a graph db!

[another edit] Another problem with graph dbs is they encourage laziness in data modelling. I would echo others' recommendations here: just start with SQL. If it gets to the point where you actually need a graph query language--and you've already appropriately considered your life choices and determined that there's some value to what you're doing--only then should you consider trying to implement something on a graph query engine. But I'm not aware of one that is actually good. That's the problem. If you're at the point where you absolutely need a graph database you are probably at the point where you need to build your own. And you'll probably fail like all the other ones.