Asking whether a relational database or a graph database or some other kind of database is the more appropriate design for a given set of requirements can be on-topic here. However, most of the reasons this question is considered a poor fit for StackOverflow in its current form are also reasons why it would be a poor fit on any SE site, even if it is on-topic here.
In particular, the requirements you specify (which would be relevant to an answer) are:
They do not need transactions, ACID, and such. They need to be queried, though.
Which is not enough to rule out any form of data storage at all. Even using a simple text file which you read into a std::map<X, Y> at startup is enough to allow basic querying. Also, I'm not sure I believe that any use case doesn't require any part of ACID; maybe you don't need things like rollback but I'm sure everyone wants atomicity and consistency at least.
Thus, as currently written your requirements simply aren't specific enough to make the question answerable. At best it is discussable, but even that discussion would mostly consist of us asking you to give more detail about your requirements. For instance: what kinds of queries, are there multiple types of entities, are there any relationships, do you ever do insertion/deletion or only querying, do you need multiple threads querying, is this a client-side only database or is it being queried via a web API, etc, etc.
