# Performance of Graph and Relational Databases in Complex Queries
## 6 Test Executions
### Test Results
#### 6.2.5 Query Performance in Task 5  
The recursive queries for Task 5 list all the sequential invoices related to the invoice with given id. The tests were performed with 100 and 1000 invoices. With 100 invoices, Neo4J outperformed relational databases when no indexing was used. When indices were used, the situation was reversed. Relational databases needed only one millisecond whereas Neo4J required 72 milliseconds and 42 milliseconds when indices were used. With 10,000 invoices and without indexing, Neo4'sj performance without optimization was poorest, but best with optimizations. Relational databases benefitted again from indexing considerably. Here, MYSQL 8.0.29 was the fastest and it was over 100,000 times faster than basic Neo4J and a thousand times faster than optimized Neo4J. MariaDB was five times slower than MySQL 8.0.29 but took only ten milliseconds. Moreover, this was  
Figure 11: Results for the queries of Task 4.  
Figure 10: Results for the queries of Task 3.  
as there are no tables that are joined by keys. Querying a graph database is achieved by traversing the graph. One of the benefits of the graph model can be seen in recursive query tests. By optimizing the query, performance clearly improved, in this case, performing even better than an SQL database with Common Table Expressions. However, with recursive queries, indexing still brought dramatic benefits for the SQL database.  
Compared with the modern databases, the old MySQL 5.1 performed well in simple query tasks. However, in aggregation tasks the performance of MySQL 5.1 collapsed. Further, MySQL 5.1 does not support recursive queries. MySQL 8.0.29 was more efficient in recursive queries than MariaDB with the long recursive query. MariaDB's efficiency in aggregate queries with a defined key was quite surprising. This may follow from the optimization algorithms of database management systems. Good optimization leads to performing the most selective operations first.  
With the invoicing database schema used in the present study, the calculation of price was conducted with complex queries. If this database was used in a real case, the usage of table views would probably be preferred to simplify the queries. When it comes to using views, it is also of benefit that an SQL database outperformed a graph database, which is a new finding in this study that was not presented in previous studies. In previous studies, Neo4j typically outperformed SQL databases. In study [4] for example, Neo4j outperformed Oracle in various tests using count(*) queries. In the present study, aggregation queries were also used but the result was different. The present study also indicated the benefit of indexing in SQL databases in many of the tests. SQL databases seemed to benefit from indexing and in some cases very dramatically. However, Neo4j did not seem to benefit from indexing, apart from when a starting point in the graph was indexed.  
In further studies, it is essential to compare other NoSQL database systems to modern relational database systems. Nowadays, the general understanding is that NoSQL database systems are more efficient than relational database systems in general. It is evident that in performance studies, indexing, optimization and query complexity should be taken into account as was the case in the present study.