At its core, Firestore is a database to store your app's data. There are many database solutions out there, but one that always shows up as an option, especially for startups, is Firestore by Google.
Firestore is a NoSQL database, meaning it is non-relational. If you don't know what kind of database is best for you, check out our article on relational vs non-relational databases. This article really assumes you have decided to go the non-relational route and are deciding whether to use Firestore as your non-relational database of choice.
Why Does Your Database Choice Matter?
Why can't you just jump in and choose Firestore? Here are the top 3 reasons why you should think before pulling the trigger on a database provider without doing the proper research.
- It is hard, but not impossible, to migrate between databases. Migrations are usually very time consuming and often even more challenging than feature implementation. The wrong choice could cost you lots of time and money down the line if you decide to walk back on your decision.
- There are limitations to consider (outlined below) that might make another NoSQL database a better choice for your project. An example would be if Firestore's 1MB document size limit is too little for your needs.
- Although Firestore is very affordable with little usage, costs start to increase as you begin to scale. In most cases, the cost of using Firestore at scale is more expensive than other providers. We'll discuss this below as well. Below is a pricing chart showing an example of how much it would cost to host an app with around 5,000 daily active users (around $12.14/mo).
Strengths of Firestore
Firestore is Very Easy to Get Up and Running
Google knows that Firestore is a solution that a lot of early stage products will be using, so they invested heavily into making sure that getting up and running is as intuitive and fast as possible. I have integrated Firestore into both mobile and web apps and setup usually only takes a few minutes from start to finish.
Things like offline support and real time support are available out of the box with very little implementation needed. As a bonus, there is a lot of great resources/documentation and community around the product.
You also benefit from the fact that many custom software developers out there will have experience with Firestore, should you choose to hire more developers at a later stage.
Firestore is Very Scaleable
Firestore is actually Google's second attempt at building a NoSQL database service, building off of the successful parts of Google's Firebase product. Without getting too technical, Firestore bakes in a lot of best practices when it comes to running a scalable database so developers don't have to. Since Firestore is backed by Google Cloud Platform, you can rest assured that your database can scale to meet your needs.
Tight Integration With Other Firebase and Google Products
If you plan on using other Firebase or Google Cloud products, then Firestore is a great choice due to the close integration between products. An example of this is that Firebase Authentication already has integration with Firestore out of the box so you don't have to worry about setting this up. This can be great if you are building an MVP or something quick and don't want to worry about things like authentication, notifications and other aspects of the backend.
Although there are a lot of reasons to use Firestore, it does not come without some limitations.
Cloud Provider Lock-in
Unlike a solution like MongoDB, which allows you to self-host on any cloud provider you need, Firestore can only be used on the Google Cloud Platform. This means that if your entire stack is on AWS, your developers are going to have no choice but to get familiar with Google Cloud as well. Although you can migrate your data, it is costly and you will no longer receive the benefits of Firestore if you migrate off. However, that isn't to say that Firestore and AWS are incompatible. They can still be used together, but you won't be able to take advantage of some of the Google Cloud products.
No Real Backup Solution
Unlike some managed database solutions such as Amazon RDS and MongoDB Atlas, Firestore does not come with an out of the box backup solution. You are responsible for creating your own solution and hosting your own backups elsewhere. It can be time consuming and expensive to set this up depending on how complex your database is.
Firestore Can Be Expensive at Scale
At scale, Firestore can be costly relative to other solutions. You can save a lot more money by self hosting a MongoDB instance on AWS than using Firestore at scale. Although, it is worth noting that many managed providers will be expensive as well. Luckily, Firestore's pricing seems to be decreasing over time so hopefully they can achieve something competitive at scale in the future.
Some Technical Limitations
There are a few big technical limitations that are worth noting as well.
- There is no support for full text search out of the box. You will have to use a third party provider such as Algolia to achieve this.
- The document size limit is 1MB, which is more than enough for most people but this could be an issue for some applications.
- The maximum depth for a sub-collection is 100.
- The maximum sustained writes per document is 1 write per second.
Like most database solutions, Firestore has its pros and cons. I believe that Firestore is a great solution for startups (especially MVPs and smaller applications) as it is very cheap with little usage and quick to set up. As you scale, you can migrate off to a more cost-effective solution as needed.
Firestore is constantly updating their offering and removing some of the limitations that others have encountered before, such as better cross-document query support and array manipulation. As their pricing continues to go down, I believe that they will become more of a comparable solution at scale from a cost perspective over time.