"Is this too far out of scope for Graph Databases?" No, it's just that ad-hoc boolean queries are better suited for other query strategies. That's not to say

"Is this too far out of scope for Graph Databases?" No, it's just that ad-hoc boolean queries are better suited for other query strategies. That's not to say that you couldn't use a graph database alongside another strategy. Neo4j, for example, has built in integration with Lucine. These sorts of boolean logic queries are best addressed by your typical b-tree index. Note that, in general, you want to prefer relationships over attributes. Depending on the application, you'd probably have something more like this: Node types: User(name, age) Country(name) Job(title) Relationship types: LivesIn() HasJob() To accomplish the boolean AND/OR queries, you'd store the key/value pairs from the User object from your comment in Lucine. But in the general cases of your app, you'd encode the relationships you need for particular, non-ad-hoc queries. Nodes and relationships can be used like pointers to create data structures in your graph. From there, standard algorithms generally apply. "Is sorting possible at all with graph databases" Often, you can completely bypass it by encoding order as a linked list. Add a relationship type: NextOldestPerson()