Using Firebase Realtime Database with complicated queries

Dhia Kennouche
2 min readJul 10, 2018

Last week, I had a client who uses Firebase as a backend service. One of the clear issues he found himself in, is that he didn’t well design his database when he created his app the first time, which when the app grew up so fast led to a big amount of mixed data, neither he could well analyze it nor the user was able to have a good UX (‘cuz of the big amount of unnecessary data he has to download despite the fact he needs it or no ).

The Issue

Let’s say we had a Node A, every action any user makes it get stored as a child of this node. So each Node N, when the number of users is only 10K for example, will end up with a huge amount of data, and when a new user uses the app for the first time and gonna need the data in Node N, he ends up downloading the data of a 10k other users!

Is there a direct Solution?

I started first by trying to re-design the database. I tried to make it flatter, so whenever the user needs some data, he will find it in independently stored in its own node and he needs to query it separately.

At first, it sounded like a good idea ( and it might be a very brilliant idea for your app to try) but the logic of the app I was working on, it will lead to a big amount of duplicated data and sometimes into a big waste of time (complicated logic + different nodes to listen to = a disaster in the UX ).

That’s why I tried to solve the issue from a different perspective. The data the app is using and working on when it starts the first time is so small. So starting from this point, I tried to store that data locally (with the magical Room ), and make as much of a complicated query (SQL Queries) as I want and implement any logic I want easily. At the same time, I kept the old logic, so when a user makes any action the app will be updating two endpoints, the one of the Firebase Database and the other one is the local one, but when he needs to query data, he will query only the local one. With this solution, we reduced the delay each user was waiting from 3 mins to 1–6 secs. (Yeah! that was like magic ! ).

Will this solution work always?

Absolutely no! It always depends on the logic of your app and the amount of or the type of data your app is working with. But keep always in your mind that whether you start small or big, always, give enough time to think well about how to store your data efficiently and what will happen when your app grows big.

I didn’t put any code here, so if you have more technical questions don’t hesitate to leave a comment.

Cheers.

--

--