Product Development June 1, 2020

Why would you NOT use Firebase?

Behdad @beeeh

Firebase offers a lot of services which make it very easy for developers to grow their product.

What I am using for my apps (iOS, Android & Web):

  • Database -> Firestore
  • Data Storage -> Firebase Storage
  • Auth -> Firebase Auth
  • Analytics -> Firebase Analytics
  • Push -> Firebase Cloud Messaging
  • Config -> Firebase Remote Config
  • IAP -> Revenuecat (WHAAAAT?! Firebase does not offer anything?!)
  • Feedback -> (Whaaat? haha)

As you can see, it's very Firebase focused. Why? It simply makes things soo easy!

One example and the reason why I am writing this love letter. As you might know, "Login with Apple" will be mandatory very soon for iOS app:

Apps that use a third-party or social login service to set up or authenticate the user’s primary account with the app must also offer Sign in with Apple as an equivalent option. [...] App updates must follow these guidelines starting June 30, 2020.

So, I decided that the time has come to implement it. I started looking at the documentation yesterday:

Followed the documentation, to be honest, got a bit confused during the final steps but hey, Firebase also has an own YouTube channel explaining their code to users like me... Quick search and I found this video:

Et voila - my iOS app now includes "Login with Apple" and it took me not even half a day.

And that's just ONE example. I could give you many more... so THANK YOU FIREBASE!

So, at this point, I am really curious, what is there against the use of Firebase... Why would you not use it? Are there even better services out there?

PS: And the best: so far, I am not even paying them because of their generous free tier....

  1. 20

    A few things that may or may not matter to you:

    1. Vendor lock-in. When Google/Firebase says "jump" you have to say "how high?" This could mean going along with API changes, unexpected price changes, or even the service being discontinued (not likely, but always possible).
    2. Minimal data portability. You're locked in to their way of handling data which is a bit different from how the rest of the dev world does stuff—if you ever want to move away, that can cause a lot of headaches.
    3. Your understanding of how software works at a fundamental level is limited. Firebase is a specific way of doing things and the mental model you learn for building Firebase apps will likely struggle to translate to a full-blown app you build on your own.

    There's nothing inherently wrong with Firebase—it's a great tool and from what I've seen it's incredibly well put together. Using it may just create headaches later (especially if your idea(s) are successful).

    1. 4

      Came here to say this exact same thing. I use basic DigitalOcean infrastructure for all my projects. Ubuntu servers, PostgreSQL, Redis and their S3–compatible object storage (and the S3 API may as well be a standard at this point).

      I basically subscribe to all the advice in here:

    2. 3

      Very good and valid points! Thanks

    3. 2

      Literally what I came here to say. Especially on the first point -- I built a number of web apps on a service called Parse, then facebook canned Parse. I know it doesn't matter to a lot of people, but you don't want to rely entirely on someone else's infrastructure.

      1. 1

        Oh yes... I remember Parse, I just started developing apps with Parse and just a few months later they shut it down...

    4. 1

      Good points and something we will take into account on our Firebase killer!

    5. 1

      Vendor lock-in will always turn me off. If there isn't an open source way to use my data, pretty much never going to use it as a core part of my app.

      1. 2

        this blew up on HN few days ago - hopefully it matures enough to be a good firebase alternative

        1. 1


    6. 1

      The service being discontinued

      Firebase being owned by Google, which has a track record of graveyard projects, its demise is only a matter of time. It's a great platform for MVPs, but when you become profitable and can invest some time and money on being independent, cut ties with any SaaS and build on a PaaS. There has been a recent announcement for an open-source alternative to Firebase:

  2. 12

    Firebase is a great tool but as with any tools, there are trade-offs. Firebase is quite upfront about them in their docs, but I'll still list a few:

    1. If your application is write-heavy then firebase won't be a good choice for you. (pretty much any NoSQL or serverless solution will not pass that check, as they are all optimized for use cases where reads overweight writes by a big margin).
    2. The pricing model is based on document reads and can quickly become very pricey if you have many small documents.
    3. On the contrary, it doesn't have some partial document querying: you get full doc or nothing. If you make documents too big, you'll have to download them, draining batteries and data plans of your customers.
    4. There is no full-text search available. You have to use 3rd party services like Algolia or ElasticSearch.
    5. You don't have any back-end and you're limited to cloud functions for any redirects or back-end work involved. Those may have up to 10 seconds cold start if they used rarely.
    6. You're limited to only one field per query with comparison operators. You can't make a query like say "price > 10$ and discount > 20%".
    7. You're limited to 200 custom indexes per project.
    8. Migrating out of Firebase can be a pain. But any migration is, so I don't really buy that point. You can always combine firebase with other back-end microservices once you start hitting its limits.
    9. The way the security model is setup requires them to do extra queries on the backend to validate security rules. It goes out of your pocket and making writes even slower. Again, see number 1.
      ... there are more limitations but for more advanced use cases.

    To make the post full, here are the strengths of Firebase:

    1. They give you a near-real-time data listeners among clients. If you have multi-player game, for example, it is gold. Implementing this from scratch will take you quite a lot of time and work to make it reliable. It even works for collections.
    2. They give you a guaranteed read performance regardless of your data size.
    3. They give you index on any field you store, included nested.
    4. Push notifications, Auth, and other services. All work well and as advertised.
    5. Client for all platforms.
    6. They take care of all the infrastructure for you and even provide you with Crashlytics.
    7. They handle network failures for you. It is a biggie for mobile-first applications. The network does suck in many places around the world.
    8. Generous free tier as you've mentioned.

    I disagree with other comments about vendor lock-in as migrating from any database project/framework for any mature project is a big pain and usually only happens for projects that have revenue and can hire tech expertise to do so.

    PS IndieHackers is built on Firebase and works pretty well, though Courtland had quite a lot of problems to overcome at some point.

    1. 1

      Thanks for your detailed list of pros and cons! Made me quite happy to notice that most of your valid contra arguments are not relevant for my current project, neither now nor in the future.

      Obviously, I also had/have some issues while developing with Firebase. However, just thinking about the sheer amount of time doing it without Firebase (either from scratch or reading into another 3rd party documentation), I am very happy about the decision I took.

      1. 3

        Yes, if you fit their use case then it is a pleasure to use it. Price can be a factor and, of course, they charge premium compare to "bare-metal solution TM", but again, people don't count the amount of work and resources needed to support your own stack like that. Backups, redundancy, network failures, logs collection, security updates, webservers to hold thousands of WebSockets, load balancing, etc. No startup should deal with that.

    2. 1

      And its a pain to just to add a simple incremental index number to each document.

      1. 1

        Compare to SQL where you have to create an index on any non-primary key field. And the most common mistake where people believe that a foreign key index is created for them.

    3. 1

      To be fair, Firestore solves #6 for most cases. Still limitations on OR queries.

      1. 1

        You're right about OR queries, I forgot to mention that. Can you send me some link on how to overcome the number 6? Sometimes, it can be helpful, though I was able to work around that until now.

  3. 3

    Unpaid taxes.

  4. 2

    COST! As your application scales you will not like the invoices you get every month. You can get into 5 figure invoices with something relatively small.

  5. 1

    The famous $30k problem or $7k problem are examples of poor code and no architecture plan, simple. These cases are not examples of Firebase problems - because the pricing model is pay-as-you-go. In these famous cases some CDN configuration, functions for the aggregations and a cache in client or server using CDN could greatly reduce costs.

    Any solution has advantages and disadvantages. The pay-as-you-go model and free tiers are very attractive for small businesses in the context of Firebase, much better than paying a monthly fee for an infrastructure and using only 5% of its capacity (when using a classic hosting, for example Digital Ocean). I have several small businesses that run absolutely free on Firebase.

    About lock-in: this is a problem that new infrastructure solutions, platform as a service, serverless structures and no-code have brought to the fore. If you are concerned about this, then create your own infrastructure, but remember: you will need to configure the entire infrastructure, worry about backups, security, redundancy, scalability, monitoring, among others ... This time could be dedicated to growth of your business. I think that small businesses, startups, solo founders should spend energy in the business, in serving customers well and meeting their needs, creating value and profitability.

    I think that if you created a SaaS or App with all Firebase services and your company has grown so much that it now needs to migrate to another service, it means that you have created a mature business and will have to hire people for this migration and possibly you will refactor or rewrite your code to improve it. It's a great problem. And refactoring or rewriting a code is not a problem for your business, it is something common in development teams in everyday life. For example, Basecamp is a consolidated company, has thousands of customers and from time to time rewrites the entire code base from scratch (currently in version 3).

    Does Netflix or Airbnb find the lock-in on AWS a problem, for example? I believe that using all the knowledge of the engineering teams on these platforms (Google, AWS, etc.) and the ready-to-use products they offer is more important than compared to a possible lock-in. Thinking about the ideal solution, creating your own infrastructure at the beginning of a business is an unnecessary financial and time cost. If you are successful and have adequate growth, you will create a team that can make all the necessary changes to your product, including infrastructure.

    Is Firebase perfect? Certainly not. Has problems? Yes. This exists on any platform. But I still think the cost benefit for small businesses, IH, solo founders is really worth it. And of course: always analyse if Firebase suits your needs. As many colleagues have said here: if you will need structured data with multiple aggregations, or you will need a customized server or you will need a programming language specific to your problem, Firebase may not be right for you.

  6. 1

    I just wonder why everyone are so careful about vendor lock-in when you can hire another people that can do it for you?

  7. 1

    Well, I started Nhost just because I did not wanted to use Firebase.


    Vendor lock-ing.
    Complicated Pricing.

    So I started to fix just that. This is our stack for our customers:

    SQL (PostgreSQL)
    GraphQL (Hasura, yes with real-time subscriptions)
    100% open source (
    Simple pricing (

  8. 1

    Personally whenever I can I give my support to smaller companies and encourage other IHers to do the same.


  9. 1

    1- Vendor lock-in. I'd rather go with a Parse hosting than with Firebase.
    2- Cost. It might be much more expensive than just using Heroku with a Parse server.

  10. 1

    I have recently released an Angular 9 application using Firebase on the 8th May using AngularFire ( if anyone is interested in Crypto) so my experience is fresh.

    In general it has been a good experience using Firebase and allowed me to achieve a lot in a relatively short time. I can align this to creating the first MVP completely Open Sourced, building the server architecture and managing multiple Linode’s. I love Linode also and would recommend using them if you want to easily manage Linux clusters.

    To keep things concise I will list the things I have liked about Firebase and the things that have been a little salty but not a deal breaker. I will compare Firebase to my Open Source Experience.

    This is all relative to a website rather than a Native App.

    HOSTING: Linode:

    Had to build Ubuntu box from fresh. NodeJS, Server, Express, Nginx, define configs, users, ufw settings and port setup, MongoDB, SSL certs etc. Once you have set up your distro it’s then super easy to clone and resize as and when you need but was time consuming to initially setup. The only thing that really used to weigh on me was my own ability to be organised and not lose passwords and leave anything in memory. Again that extends the setup time as you have to add services to guard against your own misgivings; I have many.

    $5 and you have a fixed cost with good bandwidth.

    It starts to get more expensive when you want to bring Load Balancing into the equation $20 each instance and then add extra servers so you can DNS ‘swap’ - Update one box with a release and instantly swap back if you have messed something up.

    It does become a whole job and you start to become aware that you could easily screw it all up.

    All in all around 3-4 weeks to get everything right and for me to feel comfortable as I had to learn a lot of security things and keep a spreadsheet of details.

    Firebase Hosting:

    I was concerned about the price of Firebase hosting but the simplicity of setting up was ridiculously simple - I was willing to pay an increase in price due to this simplicity. The Firebase CLI asks a couple of questions, rename prod dir? and route via index.js? - Update hosting from your CLI after building your app and you are live. DNS changes are stupid easy. To setup everything literally took 5 minutes. is still on very little traffic and the Angular App is probably more bulky than it should be but May Hosting cost has been £0.50, Non-Firebase services £0.24, Functions £0.04

    Firebase Hosting allows you to rollback code instantly which was much more expensive to recreate with Linode I found. There will be other options available to do this on Linux, I just didn’t get there.

As this point in time i’m saving money with Firebase


    Functions are the same as running your own NodeJS server. If you use Firebase Functions a forced requirement has been asked to update to Node 10 from 8 and also you have to move to the Blaze plan which means your credit card is open ended. I was on a Blaze plan already but there was a relatively short window given to update to V10. They gave some steps to update your Functions but following them through it error’d as Firebase missed out some needed steps. My experience of NodeJS allowed me to work out the issue quickly but people with less experience of Node might struggle.

    Firebase Functions:

    Cold start, cold start, cold start, cold start, splutter. Firebase Functions cold start is like starting a Lada Riva in the middle of a Siberian winter.

    The cold start issue is problematic when you are just starting out. Low traffic means a lot of cold starting.

    An example. When a new user signs-up it will take on average about 3 seconds through the Auth api. Then you want to create a new user doc in Firestore that will also be cold-starting; another 3 seconds, maybe 6 seconds on bad start. You’re already in the hole for 9 seconds at best.

    Let’s say you have a nice registration User Experience designed but you start to find you have to change your code to factor in massive amounts of delay. This means you start patch-working around your app things that are available in the auth response - Then you have to delay asking the user for more information i.e. displayName etc just in case your user document has not been created yet. This all adds to your monthly bill as you fishing expedition back to Firestore gets bigger.

    Instead of doing just clean code design you end up doing defensive code design for the potential delay pitfalls.

    These issues will not be prevalent once I reach critical mass… But first impressions matter when you are trying to convince users to hang around for more than 2 seconds before they give up and slope back to reddit.

    Firebase Functions can be tricky to setup in separate files and most devs end up with a massive long index.js file.

    NodeJS :

    A node server is easy to setup and run off heroku for example. None of the cold start issues. Not much more to say.



: I like NoSQL document stores. I like MongoDB. Firestore and MongoDB are relatively similar on first view but miles apart on use.

    Simple text search MongoDB :
    db.stores.find( { $text: { $search: “Can Firestore do this?” } } )

    This is not ‘exactly’ possible in Firebase - I have in some ways fudged limited text search with Firebase always with an eye on costs. Basically don’t do it if at all possible


    collection(’randomText’).where(‘SearchIndex’, ‘array-contains’, ‘Can Firestore do this?’)

SearchIndex: [“C”, “Ca”, “Can” "Can F”, “Can Fi”, “Can Fir”, “Can Fire”, “Can Fires”…]

    If you have a short Crypto Symbols for example BTC this is workable for a filtered search but still not ideal


    Another ‘cheat’ I use is for displayName checking is:

    collection(‘displayNames’).doc(‘displayName’).get().then(document => {

 if (document.exists) {}


    You can do a full text match on a doc id ;)

    One thing I do like in Firestore that MongoDB doesn’t have is ‘Nested Collections’. I like them.

    Firestore makes it super easy to create new index’s if you have a compound query. It will provide you a link to click to create a new index from your query.

    citiesRef.where("state", "==", "CA")
    citiesRef.where("population", "<", 100000)
    citiesRef.where("name", ">=", "San Francisco”)

    Everything else is very much the same as MongoDB

    Firebase Storage: (major flaw)

    My biggest issue with Firebase Storage. The Storage API is an observable that you can subscribe() too. It will kindly send back to you percentage complete as you upload an image. On small images this all works fine, but for a larger image it is completely off.

    It will send back 100% complete - You then ask get the Storage Url so you can download the image but this will then return a 404. It says it is 100% done, but it is not. So now I have to add a delay or keep interval hitting the endpoint until it is not returning a 404. This is hit and miss on how long it will take and it feels like you are in a Siberian Lada Riva again.


    Cloud Scheduler


    I enjoy the simplicity of this to trigger my Firebase Functions

    Linux systemd

    More effort to setup but still simple

    In Summary:

    I’m a fan of Firebase. There are some creative coding issues that you need to manage mainly around delays caused by cold starts and image upload lag. Still with these quirks the time to live was greatly sped up. My development time only to be slowed again by Typescript :/

    I also utilise ML Kit and Analytics heavily and everything being in one place is convenient.

    I do get concerned with vendor lock-in (I also get concerned with my own ability to keep servers patched and secure) as I also experienced and also Gamesparks being bought by Amazon which destroyed one of my projects.

    I feel this is less likely to happen in the near term with Firebase but that’s the risk I am taking to be able to focus more on my project code than architecture.

    tl;dr not very concise

  11. 1

    For the people who are looking for open-source alternative to firebase, checkout Supabase.

    1. 1

      They only manage the API layer. You still need to:

      • Manage everything
      • Authentication
      • Permission
      • Storage
      • Backup

      etc etc etc, all these things Firebase handles very well.

  12. 1

    "How we spent 30k in Firebase in 72 hours"

    What is your plan if your app suddenly has a $30k+ bill?

    1. 1

      I don't see that as a "Firebase" issue: I mean that could happen with any service you use, right?

      1. 1

        If your service is hosted on ec2 some other VPS service (Digital Ocean, Heroku, etc.) where you are charged a flat rate for computer resources, then you will never need to worry about unexpected bills.

        If you use pay-as-you-go services like Firebase, Amazon S3, or AWS Lambda alongside your digital ocean box, then yes, you might end up with a massive bill there too, but in theory, the DO box will be overwhelmed with usage long before your S3 or Lambda bill gets to big digits.

        1. 1

          If anything this the article in support of firebase. Devs made quite an obvious mistake and Firebase still survived 46B requests and 2 million sessions in the span of two days. Any SQL solution will be long dead with a mistake like that.

          PS you can set budget limits and be notified about situations like this. While you can't prevent them completely (we're all humans and make mistakes) but you'll know about them very early and probably be down like $100 which is comparable to a couple of hours of dev work.

          1. 1

            Any SQL solution will be long dead with a mistake like that.

            Definitely! you would quickly get an error and you would rapidly solve the problem. Firebase obscured the error making it take them 3 days (while racking up a massive bill!) to resolve it.

            1. 1

              Everything will become super slow and then you'll be lucky if you have slow queries log and it is obvious which query is a problem. Otherwise, your marketing campaign can be bust. Of course, cost-wise you don't want to spend $35k dollars on anything but as a startup, you don't want to waste your viral campaign either. Many of those people will never come back and the percentage is higher when site is slow or unresponsive.

              1. 1

                No.. you would start throwing timeout errors and your web server (which you could monitor via a free service like pingdom) would stop responding to requests and then you go fix it quickly since the failure would be very obvious (check your db analytics or use a service like scoutapm.

                Based on the article, the viral traffic did not generate enough value to offset the cost of their broken servers.

                Bottom line is that startup did not generate $30k of profit from their viral traffic. The were spending $1 to earn pennies, but their servers stayed up!

  13. 1

    I came across Flutter, it led me to use Firebase because there was a lot of content on it.
    Auth, Storage, Cloud Messaging are great.
    I use Amplitude for analytics (they have an sdk for flutter).
    The pain comes with the nosql database Firestore. I came from a SQL background and it was quite a learning curve. If you don't know how to use it efficiently, it can be very costly.

  14. 1

    nosql sucks for 99% of the usecases, it’s amazing for 1% (like realtime chat)

  15. 1

    This is one of the major reasons I pivoted to building dwata. Data management is way more tougher than I had thought. Me being a seasoned developer, I never think of this, but Firebase is proof how no one wants to tackle data design and management.

    But Firebase is a vendor lock-in nightmare, like many people here have pointed out. With dwata, my mid-term goal is to provide ad-hoc data management on PostgreSQL where dwata will create tables and manage migrations for you.

    Since schema of early stage products change a lot, I would use PostgreSQL's JSONB columns to model data that is new, where structure will probably change quickly.

    dwata will monitor when certain columns have been reused enough times that they should be converted to real data-typed columns in a table - SQL migration will be maintained for you ;) The API stays the same throughout, no impact on frontend.

    Authentication will also be tackled, but I am not sure about Analytics and other services from Firebase. Perhaps I will make it easy to integrate other existing solutions. dwata is self-hosted and open source, so no vendor lock-in.

    1. 1

      Oh, Redis for API level cache, RabbitMQ for tasks and gRPC for hooking into existing or new backend logic is all going to be there. Your app can be read or write heavy, optimizations will be done for you. Full text search through DB or Lucene.

      I am very excited about building dwata, if you are an early stage startup please let me know if you want an open, non vendor lock-in backend. Warning: this is in super early stage so lots of things are missing, but hey, I need to still market.

  16. 1

    the only issues I have faced so far is geolocation query and search, I think it is trade off for its features.

  17. 1

    Vendor lockin and the data problem issue as already said, but also the fact that anyone who may join you in development would have to learn firebase before confidently contributing, which can be a real problem once the code base grow in complexity (you understand it as you grew it, but becomes difficult to make sense of everything for someone who didn't start from scratch). It's not like firebase is used by most dev. Perhaps aws is becoming a platform most dev will have experienced using.