I'm building an application which is perfectly suited to a graph database and I have decided on Neo4J. I am in two minds as whether to store the data about particular nodes on the Neo4J nodes, or simply have a reference to an item in mongo db.


(Person: name="Bill", age=29, id=1) <-neo


(Person: id=1, uuid="some-uuid") <- neo { uuid:"some-uuid", name="Bill", age=29} <- mongo

I plan on having a REST interface to the data which might look like:


  • (neo) I would look up an individual user by the id in neo.
  • (neo + mongo) I would find the user in mongo (without touching neo).


  • (neo) Find all the friends of the user and load the nodes

  • (neo + mongo) Find all the friends of the user get the Id's and then query mongo for the data

So I guess my question is: Is there a down side to storing my data about nodes all in Neo (performance etc...) as this seems a bit more clean and simple.



  • What other data are you storing? May 13 '16 at 16:38
  • There's really no right answer to this, whether you use a single database or take the polyglot persistence approach and work with multiple databases. It's going to be up to the specific shape of your data, and how you want to take advantage of each database's strengths. In your example though where you use both, you're only storing an id in neo4j, so in that case, how are you even taking advantage of the query capabilities of Neo4j? May 14 '16 at 12:30

It depends on the size (structure) of your data and what types of queries you'll run. There can be observable performance hit if you store huge amount of data on nodes - but "huge" is difficult to define in exact numbers ;) A few guidelines/things to think about:

  • can you envisage having to run queries using more attributes for filtering - anything you want to use in queries has to be in a graph. Is that minority or majority of your properties? Personally, if I had a distribution of 20% properties for filters and 80% only used once you found the node, then I'd consider dual storage (if other factors were there). If it was reverse (80% used in queries, 20% not) - probably for simplicity I'd store everything in a graph.
  • Due to how native storage is implemented Neo should work better with smaller number of larger properties than large number of small properties. I've done some crude measurements of storing a single json of all props vs each property separately and it was a couple of times faster to import a large CSV, haven't measured reads but I expect that it would also be affected. So if you have just a few properties you'll be better off than if you have loads of them and you want to keep them separate
  • does you graph size and speed requirements actually justify worrying about it. Whilst having unused properties in mongo (or something else) might be faster, if the difference is - say - 100ms vs 200ms on a typical query, maybe it's not worth the increase of complexity of the project.

Overall, your question is certainly valid and there are projects where I've heard people moved some data out of the graph. However, I wouldn't start with this - I'd put everything into neo4j to begin with, do some basic perf testing on queries and use cases you expect, and refactor things out into mongo only if it turns out that the performance or storage size is unacceptable.

P.S. I should also mention that you'll probably see this more on writes than reads assuming you'll be clever about your reads. If you manage to get your reading queries to form returning only particular properties (and not full node) then reads shouldn't suffer regardless of how many properties are "attached". In other words, doing RETURN user.name will be much faster than RETURN user if users have loads of properties and you're only interested in the name.

Your Answer

