I found online that firebase can only handle up to 100 users. Does this mean that after 100 users sign up, you will be forced to switch to a higher plan? That seems like a very low user count.
The limit you're referring to is the limit for the number of concurrently connected users to Firebase Realtime Database on the free Spark plan. Once you upgrade to a payment plan, your project will allow 200,000 simultaneously connected users. This is not the total number of users, just the number of them that are currently running your app. This limit does not apply to other Firebase products (there are over a dozen).
I suggest reading over the pricing page carefully to understand the limits for paid and unpaid projects, for each of the individual Firebase products.
Related
I have a service using Firebase with Stripe and metered billing. I charge customers for each document they have stored in their main Collection. However, in the signup process, they have to sign up on my web site and their users and admins download the app for free from the app stores to interact.
I'm thinking hard about punting the web site sign up and just going through the app stores and paying their fee. However, I can't seem to unlock how to charge a per seat metering based on my firebase collection list. The number of seats can vary from 1 - 1,000.
The way Stripe does this is quite easy, one bill to the customer, and I update the usage every night and it bills based on the highest reported number in the period. I see greater potential in creating signup in the app. However, I can't do that with Stripe, circumventing the app stores with my model...or at least I don't think I can, and I can't figure out a per seat metered subscription setup in the app stores.
Core question:
How could I get firebase metered stripe billing to pass through the app stores?
How can I set up in app subscriptions based on per seat metered billing from firebase data?
Maybe I can get away with this if I can demonstrate to the app stores that they lack the functionality?
I am using google cloud pub/sub for receiving the push notifications of any gmail user by setting a watch on the concerned users mailbox. I am able to do that. I am creating a one topic per user in my google console project and also creating one subscription per topic. As per my knowledge we cannot make more than 10,000 topics and subscriptions in one project(GCP). My question is that can we increase this limit. I want to increase it to 100k or 10 million. Is it possible. If yes kindly suggest some resources or references, where I can read about it.
At this time, the 10,000 topics and subscriptions limit cannot be increased. It is a dimension we'd like to scale up at some point, but for now, this is not a quota for which one can request an increase.
In Firebase Authentication Limits it states that new account creation limit is 100 accounts/IP address/hour. I could not find any further explanation on this, i.e. what happens if the limit is exceeded, because it is very likely that there might be more than 100 new user creation after the launch of the app or a successful marketing campaign.
It states that "You can schedule a temporary increase to the account creation limit in the Firebase console."
Is that a paid service? How much does it cost? How long is temporary? How often can it be scheduled?
To add to the Frank van Puffelen's answer, this is easily customizable via the Firebase console: Authentication tab -> Manage sign-up quota (at the very bottom) to get this:
The IP limit is in place to protect your project against abuse. Setting a temporary increase is available to all Firebase projects, free or paid.
I don't think there is any documented limit to how often you can increase this, although that too is monitored for abuse.
As the title say: What is the maximum number of Firebase shards we can have?
I just realized that one Firebase database is not going to cut it for my project, because the real-time DB price scales very harshly. I could avoid the issue by having one main DB where I go on Blaze and a very large amount of small DB instances on spark. Alternatively, I could use storage (which scales much better), but I'd have to do some significant change in how my program works.
There is an undocumented limit to the number of projects you can have on the free/Spark plan. The number depends on the reputation of your account on the Google Cloud Platform. Since Firebase projects are also GCP projects, the limit covers both your Firebase and (plain) GCP projects.
There is no known limit to the number of projects you can have on a paid plan.
I would love to use Firebase as my primary cloud storage service for my HTML5 mobile apps, but I'm having trouble figuring out if the limit on simultaneous connections is going to restrict me from having a lot of non-realtime users as well.
At first glance, it looks like I can only have as many users as the connections I am paying for. What happens when 10,000 people download my app? If my app doesn't need real-time synchronization (polling is sometimes totally fine), is Firebase's architecture still going to limit the amount of concurrent users? Should I just go with couchDB and a VPS?
Thanks!
You need many fewer concurrents than your total expected user count. Firebase recommends 1 concurrent for about every 1440 visits, per their pricing FAQ.
So, if you expect to have 10,000 visits, you'll likely see under 10 concurrents most of the time. This keeps you well below the 200 provided by the candle plan.
(Answer copied mostly from comments. Thanks #Kato)