Had a poor experience with Spring Neo4j as it was mainly orientated to use it as relational instead of providing actual graph benefit of looking for related things in specifc ways - traversing but returning only small pieces.
Now regardless of framework or using just cypher builder another thing is I used MongoDB for GeoJSON. I thought about PostgreSQL and it could've been an easy replacement but regardless. Thig is some data should be duplicated in a proper maner you tend to use it. I used Neo4j mainly and if one is to request GeoJSON i first found paths in Neo4j and allowed objects for the user than collected just IDs and found them in MongoDB. Why? Because data relation was easy more dynamic and applicable in graph than any other DB type so an extra call is nothing compared to flexibility and speed provided with it. So I would say that Neo4j should suffice in many aspects but copying data is not a sin. In fact microservices have huge data redundancy in big projects if we are being honest. But if you tend to keep them together in monolith I think you need to pick the prime one. And keep ID references in another as easiest approach. As I said my case was geo data in mongo db had ref to IDs in neo as plan was to split it fully and have isolated geo microservice which depended on neo one for consistency and access control. As mongo is not so good with transactions I couldn't achive it nor cared about it as it was built to sync via events in message queue BUT I think transaction handled by Spring would work great in your case.
Software engineer with over 10 years experience in different technology stacks, architecting, developing, CI/CD and leading teams. Currently working with Java, Node.JS and Serverless
Had a poor experience with Spring Neo4j as it was mainly orientated to use it as relational instead of providing actual graph benefit of looking for related things in specifc ways - traversing but returning only small pieces.
Now regardless of framework or using just cypher builder another thing is I used MongoDB for GeoJSON. I thought about PostgreSQL and it could've been an easy replacement but regardless. Thig is some data should be duplicated in a proper maner you tend to use it. I used Neo4j mainly and if one is to request GeoJSON i first found paths in Neo4j and allowed objects for the user than collected just IDs and found them in MongoDB. Why? Because data relation was easy more dynamic and applicable in graph than any other DB type so an extra call is nothing compared to flexibility and speed provided with it. So I would say that Neo4j should suffice in many aspects but copying data is not a sin. In fact microservices have huge data redundancy in big projects if we are being honest. But if you tend to keep them together in monolith I think you need to pick the prime one. And keep ID references in another as easiest approach. As I said my case was geo data in mongo db had ref to IDs in neo as plan was to split it fully and have isolated geo microservice which depended on neo one for consistency and access control. As mongo is not so good with transactions I couldn't achive it nor cared about it as it was built to sync via events in message queue BUT I think transaction handled by Spring would work great in your case.
Thanks, looks like I'm going in the right direction.