To meet the demands of 5G and what comes after, telecommunications companies will need to replace their old embedded systems with new technology. One such solution could be to develop cloud-native applications that offer many benefits but are less reliable than embedded systems. Having the different units in the 5G system store their state, or their operational context, in cloud-based databases could reduce downtime in case of failing processes, but various database systems have their advantages and disadvantages. Thus, the choice of implementation must be carefully considered.   This study primarily aims to create a simulator that can measure latency, or the time it takes to write or read dummy data to or from one of two different kinds of databases. Its secondary aim is to produce use cases that mimic situations that a database for state data would need to handle and to collect measurements from them with the help of the simulator.   The simulator was implemented using C++17 and contains a simulator object and separate database clients. The actors representing the units interacting with a 5G network were created by the clients and their state data was stored in either Redis or PostgreSQL databases. Various use cases were designed with the instruction from Ericsson to simulate real-life scenarios and to measure latencies. Quantitative data analysis was performed on the collected data to compare the performances of Redis and PostgreSQL databases in the different use cases.   The study found that Redis on average worked the fastest and that its latency was largely the same regardless of data sizes, while PostgreSQL's latencies, and thus the differences between the databases, varied more depending on the scenario.   The results of the study show that Redis is the one of the two databases that operates more consistently and predictably, which may partly be explained by the fact it is mainly based in the RAM, while PostgreSQL is mainly disk-based.   Future work could involve testing the databases under higher workloads, exploring what would be the impact of running simulations in environments with reduced RAM and not letting Redis use it to its full advantage, and maybe analyzing more latency figures by creating new use cases and running them. Future work can also include an investigation of the effect of Redis database crashes. Moreover, the simulator implementation allows for changing to other types of databases.