## 6 Discussion  
Figure 3 provides a detailed illustration of the response times for SQL Server, showcasing how these times vary depending on the length of the computed path. This variation clearly demonstrates the direct influence of the number of iterations required by the Dijkstra algorithm. As additional intermediate points are introduced along the path, the response time increases noticeably due to the need for multiple executions of the algorithm. Furthermore, data from manual testing by individual users reveal that SQL Server consistently maintains a stable average response time, even when handling concurrent requests from multiple users. Conversely, Figure 4 displays the response times for Neo4j, which are markedly higher than those of SQL Server, particularly under conditions where multiple users are simultaneously accessing the system. This stark difference in performance underscores how the complexity of the underlying algorithms can significantly impact the application's overall responsiveness. Such a factor is especially critical in scenarios where timely responses are essential for the user experience or system efficiency. Figure 5 illustrates the memory usage pattern for SQL Server, showing a steady increase during operation, particularly when requests involve avoided points. This increase is due to the creation of additional virtual tables for each user, leading to progressively higher memory consumption. In contrast, Figure 6 presents the memory usage data for Neo4j running on AuraDB. The graph reveals that Neo4j's heap memory usage fluctuates significantly, ranging from 25% to 75%, on a system equipped with 8 GB of RAM and 2 CPUs. Despite the relatively small dataset involved, this variation suggests that Neo4j is noticeably more resource-intensive than SQL Server. This finding highlights Neo4j's greater demand for hardware resources, which becomes a crucial consideration in resource-constrained environments where efficient memory and CPU usage is essential for maintaining performance. The CPU performance results bring the OutOfMemory issue into even sharper focus. As shown in Figure 8, SQL Server maintains remarkable stability, even under the heaviest workloads, with CPU utilization never exceeding 1.5%. This stability stands in stark contrast to Neo4j, which, as depicted in Figure 9, experiences a sudden and dramatic spike in CPU usage, reaching 100%. This spike directly precedes the machine running Neo4j crashing, making it clear that the database struggles with high loads. To complete all tests, we were forced to reduce the number of simulated threads for Neo4j to just 30. This behavior reveals a significant vulnerability of Neo4j when it comes to handling concurrent user access, which poses a major limitation for using the database in environments with multiple simultaneous users. While increasing hardware resources could theoretically address some of these issues, such an approach may be impractical in real-world applications where graphs may contain thousands of nodes and relationships and where hundreds of users may access the system simultaneously. Scaling resources to meet these demands would not only be costly but also potentially hindered by hardware limitations. Additionally, providing prompt responses to all users is critical in modern applications. A server crash resulting in lost connections and unanswered queries is unacceptable. The findings from this experiment clearly demonstrate that Neo4j's inability to handle concurrent access reliably makes it unsuitable for scenarios where multiple users need to interact with the database simultaneously. Figure 9: Neo4j (AuraDB) CPU usage during all tests. These findings emphasize that, in real-world scenarios, there is no universal solution for data storage. The optimal choice of database technology is highly dependent on the specific requirements of the application. In some instances, a hybrid approach--leveraging multiple database systems--can be particularly advantageous.