You've asked about storage size and performance, which are very unlikely to be an issue for storing rows of two integers. What you really want to be thinking a

You've asked about storage size and performance, which are very unlikely to be an issue for storing rows of two integers. What you really want to be thinking about is the data access patterns. Are you going to be querying the entire data set in a way that can only be practically expressed or executed as a graph algorithm? My guess is no, because that's specialized and uncommon. What you want to avoid is giving up the reliability, maturity, predictability of an RDBMS unless you really have to, because you really need the secret sauce of a graph (or other specialized) database. Even if you do have graph algorithms to run, I would still recommend an RDBMS for primary storage and day to day single-animal lookups if that's a frequent use case. Load data into a secondary graph database to handle offline or one-off analysis. Unless your entire application is truly centered around graph algorithms. Switching off of an RDBMS very quickly becomes a tail-wagging-the-dog situation if you only look at the data and not the access use cases. The important thing to note is that the entity relationships alone aren't the right information to allow anyone to make a meaningful recommendation.