Why Firestore, Part III: 6 things you need to know before using Firestore

by Jakub Fijałkowski

With the rise of cross-platform technologies like Flutter, React Native, and Kotlin Multiplatform, Firestore is gaining more and more attention as it tries to solve quite a few problems with the platform. Not only it promises to replace fully-fledged backend solutions, but it also allows you to write mobile code only. But is this the silver bullet that developers are trying to find?

Last time we looked at the Firestore (and Firebase in general) and we’ve seen some of the problems it comes with. These don’t make Cloud Firestore a bad technology, no. It still is one of the easiest real-time databases to use for both Android, iOS, desktop, and web. Considering all the limitations, now is the time to answer the natural follow-up question — how to overcome these?

The short answer would be like “don’t use it” but let’s be honest here. Firestore can be a timesaver for some problems and it might be worth using it, despite all the problems. Just not overuse it and be ready to change it to something more appropriate later.

In this post, I want to give you some hints on how to use Firestore effectively and not hurt yourself in the process. Most of the time this doesn’t involve code at all — you just need to design your app appropriately :) Read on to find out how!

This is the third article from a series where we are comprehensively describing the pros and cons of using Firestore as the backend solution and database for your next mobile or web application. In this series, we will try to show you that making this decision is not a simple process and you need to analyze your app from multiple perspectives.

Posts in the series:

  1. Why Firestore, Part II: reasons to hate it [LINK].
  2. Why Firestore, Part III: 6 things you need to know before using Firestore [you are currently reading it].
  3. Why Firestore, Part IV: how to escape it [will be published around 9th December].

Would you like to learn from our past experience on what can go wrong with Firestore and Firebase and what are their biggest disadvantages and limitations? Read on to find out why!

Embrace it

  1. Security,
  2. Costs,
  3. Latency,
  4. DB features,
  5. Data modelling possibilities,
  6. Backups.

All problems can be mitigated when you acknowledge their existence. This is the main thing to remember when using Firestore. You have to embrace them and try to overcome them this way or another. You won’t solve them (at least not now), but you can keep them in check and maybe use them for your own advantage.

In this section, I will try to describe ways to handle all the drawbacks from the previous post. This is nowhere near being complete or full but hopefully, it will give you a starting point.

1. Isolate and secure sensitive data

You will have holes in your Firestore rules sooner or later if you need to do anything more complicated. This is inevitable no matter how hard you try. They are just too complex. There is a possibility that nothing bad will happen because you fix them just in time, but when it comes to really sensitive data it’s better not to leave any possibility of mistake.

My recommendation here would be to isolate the sensitive data and put it somewhere else. Let them stay in an ordinary, backend-only database and guard everything with proper, API-level, authorization. It is much easier to secure and you have the means to test it and audit it automatically (which is not possible or very cumbersome with Firestore). You can put everything else in the Firestore, but the most precious data will be kept secure.

If you really don’t want to have a separate storage, at least isolate it on the Firestore level (e.g. separate collection) and put much more scrutiny to the rules guarding this part of the DB. It will require more work but at least your data won’t leak.

2. Design your data for the pricing model

My advice? Limit the data you put there (i.e. prevent over-duplication). Add exemptions for fields you don’t use in searches. Don’t use dynamic field names. Don’t store binary data there — use GCS/S3/Azure Blobs for that and just link it. Remove old or unused data on a regular basis. Limit the amount of user-generated content there (or sanitize it beforehand). Don’t put long strings there — treat these the same as binary data. And the simplest yet often overlooked advice — design your data well. :)

3. Workaround latency

But not all hope is lost. There is always a way to hide the latency either by moving the work to the background (and e.g. preloading the data) or using some clever tricks in the UI (spinner being the easiest one :) ). You still can’t give your users any guarantees and you need to make them prepared for sporadic lags, but nothing will break if you expect it to happen.

If you have a very time-sensitive app, like online auctions where you can’t have unpredictable delays (no one likes to lose because of something that we don’t control), you shouldn’t really use Firestore. You will have a hard time hiding the hiccups and you will only anger your users. There are more places where Firestore doesn’t fit but for that, we have another section below. :)

4. Don’t put too much on it

Sometimes you have to design your data so that you can express the query (because of the limitations) at all. You might need to denormalize and duplicate the data to facilitate the query or use some strange encoding so that it is expressible (e.g. put a couple of fields into one string and search on that :) ). You need to be prepared to sacrifice some functionality or go with a more involved solution. Nevertheless, with some up-front design, you can make it work the way you want.

5. If you select it, do it the right way

There are multiple approaches to the design. DDD is one that I would recommend personally. You can find great materials for it on the Internet but I would personally recommend starting with Reso Coder’s Firebase & DDD tutorial in Flutter. It describes it well and also gives you well-modeled architecture that all your apps might use. Not only Flutter apps. All mobile (and desktop probably) apps, being it native Android/iOS, React Native, or even Xamarin.

With proper architecture and well-modeled data, you will be able to keep your app maintainable and you might manage to overcome Firestore limitations, with a scalability story at your disposal.

6. Configure periodic exports but be aware of the data loss

And remember that Firestore has no backups. :)

Cloud Firestore doesn’t fit all use cases

Proper backend

Firestore might be a viable option for a small part of the app, where you would really use its features. You will just need to maintain the programming regime and don’t succumb to the “yay, let’s use it for everything” vibe. :)

Security requirements

I don’t even think that keeping PII there should be done. I’ve seen projects that used Firebase Authentication and kept user profiles in Firestore (in addition to Auth) which isn’t inherently a bad idea. Except when you have no security rules or these are broken. Without proper authorization, this data is effectively public and you have a data leak from day one.

Latency-sensitive apps

Except when it won’t. You don’t control how Firestore libraries behave in regard to caching or connectivity. You don’t control when they sync the data. You can’t force that. This is also an implementation detail so Google doesn’t really describe how it works under the hood. If you have bad luck, one of your users might totally think that they won the auction because in the last second Firestore hasn’t sent an update.

Complex apps

You will probably also stumble upon missing features. Firestore has a query engine, but it won’t replace ElasticSearch. It has subscriptions, but these are not a substitute for WebSocket-based communication. You can attach functions to events, but it won’t replace other solutions (e.g. Airflow) when it comes to batch processing. It doesn’t even aim to do so, and you need to be aware of that.


It also has its fair share of drawbacks. Designing the data so that it fits Firestore’s model might be quite hard. You will have to address some of its limitations upfront (latency, migration possibility), keep enough scrutiny to not break things (security rules), and just get used to some things (pricing).

In this article, I tried to show you how you can address some of the limitations. I also described types of apps that, in my opinion, won’t benefit from Firestore. The features of Firestore are indeed compelling, but with all the problems with it, it just might not be worth it. You need to weigh the pros and cons and make informed decisions regarding Firestore because once selected, you might not be able to easily go back and choose something different.

But not all hope is lost. Even if you use Firestore already but want to escape it, there are ways to do so. This, and probably more, will be part of the next article, unexpected even for us, but we think is necessary. Follow us on Twitter or Facebook or other social media to not miss it!

We are a group of technology enthusiasts working together for our clients to create better solutions for their digital consumers.