I am prototyping a social network as part of a project I am working on and want to learn the right way to do it as if it were for an industry leading company.

I've decided on implementing the social network in a graph database like Neptune or titan db.

I also intend to do full text search on posts using a full-text engine like elastic search.

Here is the meat of my question.

The network has Profiles, Groups, and Posts as nodes in a graph as vertices and Friendships, Memberships, and Authorship as edges between these vertices.

I've already recognized the need to store my posts in a full text search database, so should my Post vertices contain nothing but a property "key" to reference the full-text database or also have a copy of the data?

Similarly should I really store the schema data for profiles and groups in a graph database either or should I simply store key's that point to either a document database or key-value database?

You obviously can store full schema information in a graph database and search it for pretty much anything but it seems like its the wrong utilization of the tool.


If you've already decided (and I'd agree) to store the text in an another database and a key reference to it inside the graph edge, there's no need to store a copy of text there as well, that would just give you an overhead of having to provide consistency between the databases with no benefits.

I'd place a caching layer in between the two databases (graph and fts one) as well to improve round-trip performance (that is, keep that cache storage up-to-date with the one that stores your text). That could be just a REDIS instance where the keys would be the IDs of your resources and the values are the text.

All of this implies a standardized way of keying your data between the databases to ease your pain. There's really no correct answer to your question, it all boils down to your requirements. Graph databases combined with RDBMs & KV dbs are a proven concept and are extensively used, but we'd have to have the whole data model in mind before giving a (still speculative) answer.

You will find many people stating that (and it's true) you can build whichever graph structure in a RDBMs if it's normalized enough.

But you probably shouldn't try that out as the traversal will probably be painfully complex, you'll probably just waste time.

  • This answers the first part about posts but doesn't quite address the second part about groups and profiles. I will presumably have to run queries on groups to search, for example, if I allow public and private groups I will need to search all public ones. This can be done on a graph database by putting the fields in as properties and running a match on them. The question is should a graph be used regularly this way? Or rather should that data be offloaded to another type of database such as a document store.
    – lvoelk
    May 18 '19 at 19:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.