Most modern solutions need graphs, but using a separate database creates problems.

Most IT uses RDBMS/NoSQL, but modern solutions require graph processing for connected data and AI/ML.
The problem is that by adding an extra graph-only database engine to your solution to do all the graph data processing is not an optimal solution approach:

• Where and how do you store intermediate data before it gets to the graph native structure?
• Where and how do you store and deliver the graph data processing results (which you likely need to consume from a relational structure/ a classic SQL table)?
• Where and how do you store history/historical results (graph structures are not optimized for temporal data)?
• Do you have an easy way to exchange real-time data between the graph engine and the solution relational engine?

The usual approach forces you to use two separate databases (relational and graph). This means data must travel back and forth, increasing complexity and causing performance penalties for the client application.