What are the hosting costs per month for 100,000 mobile app users for Firebase or AWS?

Be vary wary of any service that bills you purely on a per-user basis. You’re likely to be paying WAY too much.

I work at Buddy Platform - we operate the most complete, stable, enterprise-ready and feature-party instance of Parse on the market (see http://buddy.com/Parse). We have apps with many more users than 100,000 operating on our platform, but the best part is that we’re totally, completely free - at all levels of service, no matter your volume.

Come check us out - we’d love to service your mBaaS needs!

Good luck!

A very simple financial model might use cloud computing for a utility-style billing. This is where every detail is metered, giving you some exact numbers of your costs.

For example, an object storage service might cost ~$0.10/GB, so you can figure up to $0.20/user per month. For 10,000 users capping at 20,000 GB, so about $4000/month (10,000 * 2GB each * $0.10 GB). You can then make some assumptions in your financial model to denote 50% actual usage (~$2000/mo), 80% usage ($3200/mo), for budgeting and capacity planning. Depending on the site/function/etc, many users won't use all their allotment, so you can under provision and oversubscribe as part of your model if you plan for rapid capacity changes. You'll also receive discounts as your usage increases, so you achieve per unit cost savings as your usage increases.


Things differ a bit if you move to dedicated infrastructure (dedicated/managed hosting, colocation, etc) where you commit to specific configuration on a monthly basis. If you buy your servers and colocate them in a facility, you have monthly costs for the colocation and then probably a bandwidth pipe with a committed throughput rate (no matter how many bytes you transfer). If you go down this path, you'll need to identify how much your equipment will cost.

Assuming the 10,000 users above with 2GB per users = 20,000 GB or 20 TB, you may need 3x servers with 8x 2TB SATA disks each (2TB * 8 Disks * 3 servers) gives you 48TB raw capacity. Cut that in half for RAID-10 redundancy, and you have 24TB usable. If the cost of that server is $3000, then you've got $9000 in CapEx, depreciated over 36 months for a monthly cost of $83/month. Add about $500 for a cheap colocation provider (about a half rack to host the 6u of equipment, with the ability to add two more servers) and you're looking at a rough cost of $583/month. Divide that by 10,000 users and you get $0.05/user for the 2GB each (or about $0.025/GB).

You can also lease servers like this with dedicated hosting, so that you don't have to spend $9000 up front. Assuming a storage server of the same configuration above runs about $700 month, and you'd need three servers, you're looking at $2100/month in costs. Same math applies: $2100/mo divided by 10,000 users is around $0.21/user, (or $0.10/GB).

Again, this is a highly simplistic model and doesn't cover the other costs of running your infrastucture (support, server management, etc). If you're building a financial model for a business plan, you can use this as a starting point when you build a proper financial model.

I can give you very detailed answer to this question. First of all, hosting 1 millon users mean many things. For example, If you just want to host the data of 1 million users, you just need to upload it to your server and it will just require 1 server.

Now comes the interesting part. Let’s say you have an application for task management and you have 1 million users that will use your application. In this case, users will log into your application which will require processing and will also require you to configure web server and your language processor which will require more processing.

If 1 million users are doing 200k activities in your application on daily basis, and you are keeping a log of all these activities, For example, If you are creating a database entry for every task a user has created/updated or deleted, the number of records in your database will increase by 200k a day which means 1 million more every 5 days. Right now, we can host this application on a single server having 4GB RAM.

Now, you also want to send notification to your user whenever any task is due. Then you will have to execute a cron every minute that will get all the due tasks from the database and send e-mail notification to the user of that task. This will require more processing. We can now upgrade our single server’s CPU and RAM to 4 cores and 16GB RAM.

Now, We want to make our task management system paid and we want to start charging our customers to use our application. We will create an admin panel that will give use glimpse of our user’s data. It will show us how many activities users are performing, it will show us how many % of the users are regular and are performing more than X activities on our application. These kind of queries are complex and require even more processing.

So, what we will do is we will create a separate Database server which will handle all our database queries and we have to create a replica of a database server that will handle all the queries coming from the admin panel. So, now we have 3 servers. One will handle all the application processing and UI, One will handle all the database queries from user side and one will handle all the database queries from admin side.

This way, as your processing and the resource requirements of your application grows, the number of servers will increase too! 90% factors are dependent on your application.

Now it’s simple, when your number of users increase, you have to upgrade your servers and when the limit exceeds, you have to distribute processing on multiple servers.

So, this is how you calculate how many servers you require. Let me know what kind of application you are creating. I will help you with your infrastructure!

First, when talking about databases in the Firebase suite, I’m only going to talk about Firestore, and not RTDB (Realtime Database, which was traditionally known as just Firebase). Firebase now refers to an entire suite of services, which includes Firestore, RTDB, file storage, authentication, etc. RTDB is most likely going to be phased out and Google is clearly putting their effort behind Firestore.

Second, there is no manual sharding in Firestore, like there was in RTDB. Sharding is handled automatically by Firestore, so ignore the other answers about that.

Third, you, the customer, own the data in your Firestore database, not Google, so ignore the other answers about that also. If Google, and not the customer, owned that data, Firebase would have virtually no users. And, also contrary to the other answers, you can export data from Firestore. If customers weren’t allowed to export their data, who would ever use it?

Fourth, the suggestion to use SQL technology on your own physical servers (ones that you physically own) is not something that I think belongs in an answer to this question. SQL vs NoSQL and cloud vs in-house are decisions that you should have already made if you’re asking about a specific serverless provider. Clearly (at least apparently), you’ve decided on serverless NoSQL, which is definitely the most popular choice today. And between the two most popular providers, AWS and Firebase, they are designed to handle virtually any workload you throw at it. The most highly-trafficked applications in the world run on NoSQL serverless, like the Amazon marketplace, for example (AWS, obviously). If AWS can handle it, Firebase can handle it too. Google would never design its NoSQL serverless to max out at a certain number of users or level of traffic; it’s designed to scale virtually infinitely.

The only caveat to Firestore (and NoSQL serverless in general, really) is dollar cost—right now in 2019, anyway. Firestore was considerably more expensive only a year ago than it is today, think about that. I think NoSQL serverless will undoubtedly continue to become cheaper, including Firestore. But, right now, with a relatively large userbase, NoSQL serverless, like Firestore, can get expensive. But so can doing it all in-house. An in-house solution still comes with bandwidth cost, in addition to hardware and human cost. Hiring qualified backend engineers to build and maintain an in-house setup is not cheap (hundreds of thousands of dollars a year). Firestore (and DynamoDB) have excellent price calculators to help you predict your costs and you may be surprised to see how cheap it is with a modestly-sized userbase, even with 100k users.

At a very high level you are only concerned with requests per second. Not all of your users will be active every second. You would need to estimate how many users out of the 1M will be active per second on average. Once you figure out that number you can setup your software on a cloud server and run a load test to see how many requests per second the server can handle before it chokes. You may need to scale out or scale up to hit your requirement. You will also want to look into autoscaling and geo-redundancy, and caching.

Edit: I did some digging for fun and found this article: WhatsApp Now Handling Record 27 Billion Messages Per Day. This count includes both incoming and outgoing messages. They are processing (on average) 312,500 messages per second!

Lets assume that WhatsApp has load tested all the different variations of virtual servers offered by a cloud provider. I will use Azure in this example because the pricing is simpler to me than AWS. Each virtual server on Azure has a cost per hour. Since WhatsApp isn't doing massive scientific long running calculations for each request, RAM isn't as important so the high memory servers would be a waste of money. This leaves us with the following server options:

XS - Extra small VM (1GHz CPU, 768MB RAM, 20GB Storage) - $0.02/hr
S - Small VM (1.6GHz CPU, 1.75GB RAM, 225GB Storage) - $0.08/hr
M - Medium VM (2 x 1.6GHz CPU, 3.5GB RAM, 490GB Storage) - $0.16/hr
L - Large VM (4 x 1.6GHz CPU, 7GB RAM, 1,000GB Storage) - $0.32/hr
XL - Extra Large VM (8 x 1.6GHz CPU, 14GB RAM, 2,040GB Storage) - $0.64/hr

Lets pretend WhatApp installs their software on the ExtraSmall server and runs a load test. After the load test completes, they check the profile logs on the server and sees a bottleneck right away with CPU. This server won't work so they then try Small, Medium, and Large. Once they try the Large server, the memory bottle neck goes away and they are able to process 1000 requests per second. For fun, the try Extra Large. They realize they get the same performance with Extra Large. The bottleneck becomes the network. They move back to Large to save money. There is no return on investment with Extra Large and they can process 2x as many messages by purchasing TWO Large servers instead of ONE Extra Large.

Lets assume (Again) that the Large server can process 1000 requests per second. To process 27 Billon messages a day, the target request per second is 312500/sec. Divide that by 1000 and you got 313 large servers. The total monthly cost for the servers on Azure would be $74,519* a month. Wait just a second here.... Load will change throughout the day right? Yup. That's where autoscaling comes in. You may only be running half of these servers in the wee hours of the night when usage is down. You will need to run MORE than this number during peak times.... but since this whole thing is just an assumption nightmare, I'm going to keep it simple and say 313 servers run 24/7.

Another thing to note. I'm not calculating charges for traffic, database servers, caching servers, traffic managers, queues, table storage, etc. A lot goes into setting up an scalable infrastructure even on a cloud provider. But, with that said, the bulk of the bill will be the servers. Whats another 5-10k/mo for the extra stuff anyways? :)

This is a question I get from a lot of clients as many of our products rely heavily on Firebase. The answer is very dependant on your application but in almost all cases this will never be a problem.

Where do the costs occur?

If you look at the Firebase pricing plan you can see that data is the main constraint for the pricing brackets. When you move up a tier you get various increases in data allowances as well as more database operations. This means you need to look at what your app does to see the impact of more users.

What does my app do?

This is the next question you need to ask yourself. Many apps will be dealing only in text strings meaning the data amount is very small. Images would be a step up from this and videos another jump in data usage. You need to think about how often your app stores this data. It might be that you only upload a single image for each user or it could be that you send multiple images while using. In both these cases the data usage will vary hugely.

Before worrying about how you will cope with 1M users think about how the app will fare with 1–10k users. In Firebase’s case you will probably be on the free tier (as long as you are not guzzling data) up to 100k users.

Think about this for a moment. You will have 100k users on your app. Even if you only add advertising you should be able to make the $25 a month to cover the Firebase FLAME costs.

The motto I use with my clients is this:

By the time you need to start worrying about backend costs for your app you can stop worrying about backend costs for your app

Once you reach the amount of users to requiring you to start payment you will have a successful app with a big user base which can be leveraged to start paying you back.

Should I use Firebase?

This is the final question you should ask yourself. Up until now this question could have been about one of the many different backends on offer.

If you are unsure I would be inclined to say: YES use Firebase!!

They are a great company and offer a fantastic product. Being owned by Google and having recently updated all their code they are unlikely to close down (RIP Parse). They also provide extensive and clear documentation and great support. There is a huge online community meaning sites like this and Stackoverflow have a huge number of questions to help you.

It is worth looking at your app though. Firebase does have some disadvantages:

  1. There is no easy way of querying data
  2. There is no way of executing code on the server

This is what should be researched when looking at whether Firebase is the right backend for you and even these can be mainly mitigated by using a separate server to control these tasks.

Conclusion: Unless your app is very data intensive then you won’t meet any of the data caps. Firebase will help you get your app online quickly and cheaply before scaling excellently once the users start pushing the upper limits.

NOTE: I would never recommend someone building their own backend when starting a new app. It might be that you have the skills to do it but in the long run it will cost you more (in your valuable time) than using another provider. Once your app is a great success and you are paying monthly fees to a backend then you can invest the money in creating a custom backend which suits your data type. Creating it yourself also requires a huge amount of invested time. If your app fails then this time is completely wasted.

We'll, let's start with the understanding that number of users is a really poor metric for this since it doesn't lead us to understanding how much load there will be at any given moment. Given that you are talking about chats your best option for connections is web sockets. Leaning on some testing on the internet it seems like holding 1M connections open would require a minimum of an r3.4xlarge (or combination of smaller servers) at just about $1,000 a month. Storage on S3 is trivial at $0.23 per GB. You'll need a database, probably a graph one to track relationships, maybe an additional relational one for other purposes. That's another couple of servers, depending on how much you're traffic is probably another $300 - $500 a month. Throw in bandwidth and ELB and you're looking at a floor of maybe $1,600 / month. Depending on the language, runtime and types of actions it could go up considerably from there.

A very simple calculation scheme, for which it is required to approximate the number of application users and the maximum storage limits for each of them. The rough estimation is simple: if the cost of storing the object is $0.1 per GB of space per month and your application is calculated, say, for 5000 users, with a limit of 2 GB, the result of multiplying all the numbers (5000 × 2 × 0.1) the monthly cost of the server would be $1000.

But, you can get the same in less than $200 from HostNOC with these specifications;

  • CPU: Intel E5-2670 2.60 GHz 16 Cores / 32 ThreadsRAM: 32GB DDR 3
  • HardDisk: 1 x 240 GB SSD & 2 x 500 GB SATA
  • Bandwidth: 1 Gigabit Port – 20 TB

It is important to understand that this calculation gives only an approximate cost of required hosting. The actual number of users may differ, and each user will not necessarily use all the space provided to them. Thus, you can make an assumption about the actual use of the server space (as a percentage of the initial number of users and disk space) and use this coefficient to adjust the appraisal.

It doesn’t matter.

Whenever you have a website or application that has “users”, the total cost is quite uninteresting.

What matters is “cost per user”. If you have a $5 a month server and 10 users, the cost per user is $0.5. If you have servers for $1,000,000 a month and 1,000,000 users, cost per user is $1.

The next interesting metric is “income per user”. Let’s say you have the 1 million users costing you $1 each every month. But they generate income of averagely $1.10 a month, then you have a profit after hosting costs of $100,000 a month, which isn’t too bad.

This way of calculating costs can be scaled up and down, for instance average ad income per visitor of a few cents. How many you need to pay for the server?

AWS. One t.medium server, one db.t.medium for the backend database, add a load balancer in front of the server, Route53 for DNS, modest I/O, should be about $90/month with the option to get as big as you need to quickly, if the need arises.

You'll want to use S3 and CloudFront for the images as well, BTW.

Hi,

We have helped several large and small companies setup their AWS infrastructure, as well as built 100's of web/mobile apps in the last 8 years. Although its highly recommended to look for investment after you have built a decent userbase, The AWS free tier will surely not help you take the load of 100k users. In fact it will not be enough to even help you cross 5k/10k users.

Regards,