Firebase Performance: Firestore and Realtime Database Latency
Tags: firebase, firestore, performance, latency
Published: 2020-02-19 13:10:49

## Firestore and Realtime DB are ~10-20x slower than a simple websocket broadcast!

(This was originally published last year on [medium](https://medium.com/@d8schreiber/firebase-performance-firestore-and-realtime-database-latency-13effcade26d), I thought this is still relevant and hope for some more discussion here ;-) )

### Why
While investigating the technology stack for a new idea (UNO(tm)-like card game), I wondered what latency to expect from the Firebase products Firestore and Realtime Database - i.e. how fast would actions/events from one user propagate to another user. As my google search did not turn up anything useful, I ran some tests and want to share the results here, in case other people run into the same question. (Of course feedback about possible improvements or optimized setup is always welcome!)

### Setup
In this setup we actually measure the round trip time (RTT), the "latency" (time of event from user A to user B) can easily be estimated as:

```math
latency = 0.5 * RTT
```

![Sequence diagram measurment setup](https://dev-to-uploads.s3.amazonaws.com/i/37bumymvb6r7kbgawcbj.png)
<figcaption>Sequence diagram measurment setup</figcaption>

For both Firestore and Realtime Database the sender (user A) creates a new document in a predefined collection (list). As soon as any other client (user B, C, …) receives this document it adds a response to the document. The sender measures the time between creating the document and receiving the response update.

As a baseline scenario, I added a simple websocket server that broadcasts messages to all connected clients.

The tests were run with both/all clients on the same machine, located behind a 50mbits connection in Frankfurt/Germany (other locations showed similar results though). For the Firestore the location europe-west was selected. The websocket server was deployed on a micro instance located in europe-west3-c.

For the test results below, 10 timings using the same connection with an interval of 1 second between each was performed.

The complete code can be found here: https://gitlab.com/daniel-sc/performance-test-firestore.

### Results

![Timings using Firestore](https://dev-to-uploads.s3.amazonaws.com/i/v4xiy0ex5pwa60y9jubj.png)
<figcaption>Timings using Firestore</figcaption>


![Timings using Realtime Database](https://dev-to-uploads.s3.amazonaws.com/i/ihx2b0pfg2q4rgq15vlr.png)
<figcaption>Timings using Realtime Database</figcaption>


![Timings using websocket](https://dev-to-uploads.s3.amazonaws.com/i/z25mc2bs3fy0odklm2sq.png)
<figcaption>Timings using websocket</figcaption>

As you can see RTT for **Firebase is ~1500ms** and for **Realtime DB ~600ms**. Compared to the baseline scenario of a simple **websocket broadcast with an RTT of ~40ms** this is an tenfold increase. Even more important is the fact that this difference has a severe impact on the user experience. For a (fast paced) card game a latency on the order of 0.5 sec might already be over the edge of the acceptable range.

###Disclaimer
Of course the firebase services offer a lot more than just forwarding events, especially regarding reliability, persistence etc.

Further resources:
* https://firebase.google.com/terms/service-level-agreement/ (not really conclusive on latency)
* https://firebase.google.com/docs/database/rtdb-vs-firestore#reliability_and_performance


Please share your thoughts on this!